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Introduction: 
APL’s place in commercial computing 


This book is about the use of APL in commercial computing. It does not pretend to 
be a definitive text; rather an exploration of possibilities;an attempt to put together 
in a reasonably logical order my experiences of writing a totally new breed of 
commercial system. 

I suspect that APL may come to be classed as one of the happiest accidents 
ever to befall computing. On the face of it, the APL notation has virtually nothing 
to recommend it to the commercial user: it is the antithesis of everything he 
expects from a programming language! It is terse in the extreme, needs specially 
adapted keyboards and printers, and is interpreted rather than compiled. Now 
everyone knows that commercial systems must be easy to maintain and efficient 
to run; what on Earth can the business user want with a funny Greek language that 
is interpreted backwards?! 

What I hope to show in this volume is that there is an enormous tract of territory 
which has been left largely unexplored and under-exploited by the traditional 
computing methods. In general I am talking about systems for planning, decision 
support, and management information -- systems where change comes unexpectedly 
and often, and where the need to react quickly is paramount. I am convinced that 
APL is by far the best tool yet invented for building such systems, and I hope 
that in my first few chapters I can pass some of this conviction on to you. However, I 
am also sure that APL, like all powerful tools, is capable of doing a great deal of 
damage if mishandled; equally much of its potential may never be realized if it is 
used excessively cautiously! 

In the central part of the book I want to develop a philosophy - and eventually 
a methodology - for system design with APL. This I hope will show you where you 
can best use APL, and how you should set about building an APL system. The 
material in Chapters 8-11 covers in detail the APL functions and idioms which I 
have found most helpful in design, maintenance, and documentation. I have also 
gone to some lengths to include a number of timed examples, which I hope will 
demonstrate that a well written APL system can often provide a more efficient 
answer than a similar system in a compiled language. 

Perhaps I should make it clear that this isnot a textbook of APL - if you want to 
find out in detail what all these funny symbols do, then the Appendix reviews a 
selection of the available literature. However, I think that a couple of chapters 
(4 and 8) could well be of interest to an APL novice, as examples of the way an 
APL program looks in practice. The same applies to parts of Chapter 10, where I 
have used some screen-design functions as an extended example of the way an 
APL application should be structured. 











To say that interactive computing is moving fast would be the understatement of 
the decade! I have no idea where we shall be in 10 years’ time, but I’m sure that 
many of the systems being written today will still be about - maybe much modified 
- then. Accordingly I am going to devote my final chapter to a decidely speculative 
look ahead, in the hope that what we build today can at least form a firm foundation 
for the systems of the future. 


Chapter I 
A break with the past 


‘That funny Greek language that executes backwards’ 
Anon. 


APL is not a computer language. It is a general purpose mathematical notation, 
developed independently of computers, which has been slightly adapted so that its 
expressions can be evaluated by computers in a tailor-made environment. This 
distinction is fundamental; it makes a nonsense of any attempt at point-for-point 
comparisons of APL with the FORTRANs and COBOLs of this world, and it 
explains much of the culture shock felt by anyone trained in a conventional language 
when he or she is first faced with APL. In this chapter I hope to achieve two 
things: first, to emphasize the gulf between APL and conventional computer 
languages; secondly, to show that the time-honoured methods of systems analysis 
were a consequence of these languages, and that APL makes much of the con- 
ventional wisdom obsolete. 

I think the best way to start is with a bit of history, so I would like to begin with 
a very brief review of how (and why) computer languages came about. In the 
early days, the only way to instruct a computer was to enter the binary codes 
(which drove the electronics) directly into its memory. It is still theoretically 
possible to do this, and in fact it is coming back into fashion with home computers, 
as hobbyists rediscover the early days of the art. The biggest problem with ‘machine- 
code’ programming is the difficulty of grasping what all these codes do. The human 
brain can cope with logical concepts like ‘Add the contents of the memory at 
location 457 to the Accumulator’ quite well, but ‘10000110’?! So were born the 
first ASSEMBLERS, the first real attempt to communicate with computers on 
our terms. 

What an assembly language does is to automate the conversion of logical concepts 
into the binary signals needed to instruct the electronics. It also lets you give names 
to areas in the memory, so that you could write the instruction above as something 
like ‘ADD A, SALES’, assuming, of course, you tell the computer that SALES is at 
memory position 457! To write a computer program (i.e. a logically arranged 
series of instructions) in an assembly language is obviously a far less daunting task 
than writing it in machine code. What is more, once the program has been assembled 
it will make very efficient use of the computer; which is why assembly language is 
still used wherever the efficiency of the resulting program outweighs everything else. 
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Assemblers, however, are only the start of the story. Since even quite clever 
computers can recognize only a hundred or so different instructions, an assembler’s 
repertoire is terribly limited. Before real-life problems can be tackled they must 
first be expressed as a sequence of these instructions; this is often difficult and 
always time-consuming. To see what I mean, take an (ostensibly) simple problem 
and see just what a sort of meal the assembler language makes of it. 


‘Add up SALES, and call the result TOTAL’ 


Using the assembler for the popular Z-80 micro-computer, the result is something 
like this: 


XORA clear the accumulator (‘A’) 
LD B,52 set a counter (‘B’) 
LD HL,WEEK1 set pointer to first figure 
LOOP: ADD A,HL) add the data pointed to by HL to the 
accumulator 
INC HL move the pointer up one 
DEC B decrement counter 
JPNZ,LOOP go round again if counter not zero 


LD(TOTAL),A move the result to TOTAL 


Again I am assuming that at some stage it is told where it can find WEEK1, and 
where it should put TOTAL. 

What started as a nice straightforward job of adding up a few numbers has 
turned into eight separate operations, half of them being done 52 times each, 
none of them obviously relevant to the problem. Imagine trying to write a market- 
forecasting program in a language that takes eight statements to add up one lot of 
figures! All right; now imagine trying to maintain it!! 

In the computer industry a need perceived has tended to mean a need satisfied, 
and it was not long before our little problem looked more like this: 


TOTAL = 0; 

DO I = 1 TO 52; 

TOTAL = TOTAL + SALES (1); 
END; 


which is roughly the level computer language reached 20 years ago, and where it has 
remained ever since. It is the sort of thing programmers have come to expect: an 
accumulator is cleared; a control structure is defined which sets, then increments, a 
counter; each value is added in turn into the accumulator. In fact it is doing exactly 
what the assembler programs did, which is not too surprising since it will sooner or 
later be compiled into something virtually identical. However, eight pretty meaning- 
less statements have been replaced by two intelligible ones and one control structure, 
and at not too great a cost in efficiency. The high-level languages struck a balance 
between man and machine: the programmer was used many times more efficiently 
and the computer only slightly less so. The surprising thing is that the equilibrium 
has held for so long, and that it is only now being broken by something which was 
never designed as a computer language in the first place! 











In APL, the solution to the problem would be 
TOTAL++/SALES 


No control structure; no accumulator to clear; no mention of how many numbers 
there are to be added up. Just a straight statement of what is required: TOTAL is to 
be given the sum of all the numbers in SALES. No wonder it comes as a bit of a 
shock to someone who’s spent his working life with a conventional computer 
language! The odd thing is that although APL is far quicker to program than, say, 
COBOL, it also makes pretty efficient use of the computer. It doesn’t just tip the 
scales in the balance between man and machine; it actually moves the knife-edge 
right out of the programming department and into the world of the systems analyst. 

The high-level languages were only one element in the computer industry’s 
struggle to make better use of its programmers. The other was the foundation and 
development of Systems Analysis. To see how and why this came about I propose 
to take another look into the past, starting with some aspects of the commercial 
systems which were (and in some cases still are) written in assembly language. 
These were almost exclusively automated versions of existing clerical jobs: things 
like wages and invoicing where legions of clerks were employed to do simple, 
repetitive, easily codified tasks. The early computers with their assembler systems 
became the machine-tools of the clerical world. They were undoubtedly fast and 
efficient, and they replaced many jobs, but some of the other characteristics of 
the machine-tool came too and these were less well received. For a start they were 
very expensive so they had to be worked 24 hours a day to get value for money. 
Then companies found they needed a surprising number of highly trained specialists 
to drive their new machines, and they began to discover one or two fundamental 
truths about the developing art of computer programming. 

To write really good assembler requires a very special kind of mental discipline 
and application. Even in rather simple programs it is all too easy to forget to clear 
the odd accumulator here, or set the occasional pointer there; and so, hardly 
were the first primitive systems out of the egg when the first program bugs began 
to appear. Companies who had just enough programmers to keep new systems 
coming suddenly found that they needed as many again to debug the systems they 
already had. Then, to add insult to injury, the company’s requirements might 
change, and the programs had to be amended to match. 

At this point these early systems had nearly reached the end of the road, because 
there is a pretty strict limit to the number of times you can patch an assembler 
program and still have any reasonable expectation of it continuing to function. So 
what were companies getting from this first generation of clerical machine-tool? On 
the plus side efficient, labour-saving clerical operations; on the minus side an 
expensive piece of equipment which needed specialists to run it, and which was not 
flexible enough to adapt to changing needs. 

By taking away all the mundane tasks needed to program at the machine level, 
the high-level language obviously increased a programmer’s productivity enormously: 
but it could not solve the problems unaided. The other vital element was the birth 
of Systems Analysis. What the systems analyst did was to break down the original 
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problem into logical units which corresponded to processes the computer could 
handle. Because it could only read information in a rather limited number of ways 
(usually 80-column cards in the old days) some form of data preparation was 
needed; bits of paper with abbreviated scribbles were fine for the clerks, but had to 
be rigorously codified and neatly transcribed before they were fit for the computer 
to see. Then, of course, all this data had to be carefully checked and stored away 
somewhere. It could then be sorted, merged with other data, stored away somewhere 
else, processed in all sorts of ways, finally to emerge on to paper as the output from 
the system. 

The benefits of breaking a system down this way were numerous: each of the 
units could be tested separately before being linked together; a small fault in one 
section could be trapped before it did any damage; and future change could be 
allowed for by isolating those parts of the system most liable to alter. 

There were, however, some drawbacks. Each link in the chain meant a program, 
and before any of these programs could be written the programmer needed to know: 
what information was coming in; what the program had to do with it; how it was 
to be passed out. Consequently he could not really start programming until the 
whole system was designed down to the final detail, and the last thing he wanted 
was a change in the design half-way through. These constraints lead inexorably to 
the classical methods of systems analysis, followed by computer departments the 
world over: | 


@ First, define the problem: make absolutely sure that you know exactly what 
your clients want, and what information you need to give it to them. 


@ Second, analyse the problem: break it down into steps a computer can cope 
with; make the basic information available as input data and decide how the 
output data is to be presented. 


@ Third, program and test all the individual steps and put them together to 
form the solution. 


© Fourth, document the solution thoroughly, present the results to the client, 
and hand over the finished system to the operations department for day-to- 
day running. 


When this method was first devised, the systems it was applied to were by and 
large well understood, logically organized clerical processes. Accountancy, for 
example, follows a series of strict rules which have been known for centuries; all 
the analyst needed to do to turn these into a workable computer system was a bit 
of transcription. Likewise payroll, sales ledger, inventory control: although less 
formalized the rules were well established and, equally important, they were not 
likely to change suddenly. In short these were ideal candidates for the design 
method that had grown up around them! Unfortunately for the developing com- 
puter industry, the supply of conveniently predigested problems was not inexhaust- 
ible. As the influence of the new design method spread deeper into company 
systems it was increasingly faced by tasks which were less well defined, and more 
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liable to unexpected change; in fact it found itself out of its depth. To see what I 
mean, take the (apocryphal) story of a keen young analyst who is told to go away 
and computerize part of a typical company planning system. 

Contrary to popular belief, the planning and control procedures of most com- 
panies are not neatly organized into a set of rational decisions taken on the basis of 
smoothly flowing information. Instead they have developed through a series of 
historical accidents, have little obvious logical structure, and such rules as they do 
have are riddled with exceptions. When the analyst applies his tried and trusted 
methods to these areas, a possible recipe for disaster goes something like this: 


© Defining the problem. The analyst spends many happy weeks tracing infor- 
mation flows and interviewing all and sundry in the planning department. At 
the end of this time he has a perfectly clear picture of how the department is 
supposed to work; because this is how everyone in it has told him it works. 
Perhaps they even believe it; more commonly they just say the things best 
calculated to stop him asking awkward questions. Anyway, he can now 
confidently proceed to stage 2.... 


è Analysing the problem. This will take several months, by the end of which 
time the planning department will have long given up hope of ever seeing that 
nice young man again. 


© Programming the solution. Assuming the analyst has made a good job of stage 
2, it should not take longer than three or four months to program and test 
his system. By this time the planning department are either thoroughly 
cheesed off, or have given the whole idea up for lost. 


è Implementing the solution. The analyst books a conference room for the day, 
lays on coffee and biscuits and delivers to the senior members of the planning 
area a beautifully professional presentation of the benefits of his system. 
They consume his coffee and nod wisely .... 


What do these wise nods actually mean, and what will the future of the system 
be? Here are four possibilities; you can probably invent several more! To take the 
worst case first: the nods may imply full agreement with everything the analyst 
says. The system is then imposed from above by the planning manager and his 
clerks are told to make it work. Since the system will probably have little relevance 
to the way their job is actually done it may not impede them a great deal. The 
input will be given the minimum of thought and the output will quietly proceed to 
the waste-basket without getting in anybody’s way. Of course if the manager 
actually insists on their using the system quite a lot of damage may be done before 
the whole project is abandoned amid endless recriminations. The resulting bad 
blood between the manager, his clerks, and the computer department may last 
for years. | 

A second possibility is that the managers have enjoyed the coffee, but failed to 
understand a word of the presentation. This is much less damaging, as although 
they will certainly adopt the system, their future interest in it will be confined to 
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its value in impressing visiting directors. It will, indeed, fulfil this function quite 
admirably, as no director is liable to spot that most of the master files are several 
years out of date and that no-one actually seems to be using the system any more. 
However, no actual harm has been done to the company’s operations, and the 
planning and computer departments at least remain on speaking terms. 

A third possibility is that the planners have a pretty shrewd notion that some- 
thing is not quite right, but, having been sufficiently doped with coffee and blinded 
with science, lack the confidence to say so. Of course they will not actually accept 
the system and the computer department may well waste a lot of time and energy 
trying to find out why; but all in all this seems the best outcome of the three. The 
potential for future co-operation between the planning and computer departments 
remains, and the only hurt feelings are those of the analyst. He can at least comfort 
himself with the knowledge that he did everything right! 

Of course there is a fourth possibility: the analyst’s view of the process may 
correspond sufficiently closely with reality that his system will function and will 
produce useful results. Unfortunately this is not the end of the story; in defining 
and analysing the problem he has perforce imposed upon the planners’ world a 
structure of which they are not aware. When change comes to the system it may, if 
the analyst is lucky, fall within his defined structure; but there is absolutely no 
reason why it should. If it does not then nothing short of a total re-design will 
keep the system going, and no computer department can afford too many of those! 

To recap then; in order to make better use of its precious programmers the com- 
puter industry came up with two things: the high-level language and Systems 
Analysis. This combination has successfully tackled a wide range of business prob- 
lems, but can also fail disastrously when applied to areas for which it was never 
designed. Where then does APL fit into the picture? My basic thesis goes as follows: 
APL was designed as a way for people to communicate with each other, not as a 
means of instructing computers. It allows us to talk to them on our terms, hence it 
is inherently a more suitable tool for programming systems where the interaction 
between man and machine is paramount. In addition, the sheer speed with which it 
can be coded makes the whole carefully constructed edifice of user-analyst-pro- 
grammer obsolete; indeed the extra line of communication may often be a positive 
handicap. Either analysts do not need programmers to do their donkey-work, or 
programmers do not need analysts to predigest the user’s requests! 

Whichever side you view it from, the relationship becomes meaningless. From 
now on, I shall try to use terms like ‘system designer’ and ‘programmer’ inter- 
changeably to imply people who create and build computer systems; not to refer 
to different levels in a hierarchy. 

I would like to round off this chapter with a story I heard recently of a group of 
programmers who won the right to join a particular union because ‘.. . they do not 
take decisions, and do not exercise management responsibility’. I fear that if their 
company ever adopts APL, the programmers may well be forced to leave that 
union! More seriously, I do believe that the social distinction which has built up 
between analysts- who give orders, and programmers - who take them, may 
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significantly inhibit the development of APL in big companies. In particular it 
places a terrible handicap on those who would follow the philosophy expounded in 
Chapter 2 - design by evolution. 


Chapter 2 


Design by evolution — where and why? 


“Managers do not solve problems; they manage messes.’ 


(Ackoff) 


This chapter is not about APL as such, but about the design philosophy that under- 
pins much of the rest of this book. It is not easy for me to give hard and fast reasons 
why I feel that evolution will often succeed where analysis fails; basically my belief 
is a pragmatic one - I write systems this way, they get implemented, and they work. 
However, as a starting point, here is another version of the tale of the keen young 
analyst whom we left feeling so despondent in Chapter 1. 


@ Stage I. He spends a few days in the planning office talking to anyone who 
has the time to see him. By doing this he both gets to know the people, and 
identifies a few simple needs that a computer could satisfy. 


@ Stage 2. He takes another couple of days to knock together some simple 
utilities, which, although pretty basic, can be hooked together to produce a 
system which actually helps the planners in their day-to-day work. Of course 
he doesn’t bother about flashy VDU layouts or elegant reports; nor does he 
mind too much if the system falls over the first time someone enters some- 
thing unexpected. 


@ Stage 3. He moves a terminal into the planning office for a day, explains what 
he’s done so far, and gives the planners a quick demonstration of the pro- 
grams. Their first reaction will probably be astonishment that anything, 
however primitive, could possibly be working so soon. Having spent an hour 
or so playing with it, they will get over their initial euphoria, and will start 
saying things like: ‘I know I said . . . but what we really do is...’ or‘... 
couldn’t we use this for...’ or‘... yes, that will work fine until . . . °. With 
a bit of luck the analyst will be able to make quite a lot of changes on the 
spot; he may even suggest some possibilities the planners themselves haven’t 
thought of. By the end of the afternoon his major problem is liable to be res- 
cuing the terminal from the planning office! 


@ Stage 4. He now knows enough about the planning process to be able to re- 
write the initial draft into a reasonably robust first system. This will largely 
consist of the utilities he wrote for Stage 3, hidden under a bit of dialogue. It 
can, of course, be given piecemeal to the planners, and the design need never 
be totally fixed. 
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By the time Stage 4 is installed this approach has gone some way towards 
regaining the confidence of the planning management, and it has secured the active 
co-operation of the planners in developing the system further. This time what the 
analyst has done is to lay the foundations of a successful symbiosis between the 
computer’s number-crunching power and the planner’s lifetime of experience. As 
time goes on the planner will gradually change his way of working to make better 
use of the programs he has been given. At each change new horizons will open up, 
until the point is suddenly reached where a (computer-assisted) clerical job has 
become a genuine partnership between man and machine. Although the system will 
continue to evolve indefinitely into the future, at this point the analyst can cer- 
tainly chalk up a successful implementation. 

At this stage you may be asking: if this evolutionary approach is so marvellous, 
why have we been wasting all these years doing systems analysis? One answer is that 
until recently the tools to do evolutionary design (i.e. interactive computing, and 
especially APL) have been either unavailable or terribly expensive. Another is that 
it’s very much a case of horses for courses: systematic design will always dominate 
in the world of large, stable systems. It’s just that most of these (in big companies 
anyway) have already been done; the pressure for new developments is coming 
increasingly from areas much more suited to APL and the analyst-programmer. 

Incidentally classical Systems is not the only discipline to be feeling the wind 
of change. For many years the practitioners of Operational Research (OR) (among 
whom I number myself) have been building increasingly sophisticated models and 
using them to solve company problems. To see which way OR is moving, here is a bit 
more of Professor Ackoff’s address to the 1978 UK Conference. 


“Managers are not confronted with static problems that are indepen- 
dent of each other, but with dynamic situations that consist of complex 
systems of changing problems that interact with each other. I call such 
situations messes. Problems are abstractions extracted from messes by 
analysis... .’ 

‘Because messes are systems of problems, the sum of the optimal 
solutions to each component problem taken separately is not an opti- 
mal solution to the mess as a whole. The behaviour of a mess depends 
more on how the solutions to its parts interact than on how they act 
independently of one another.’ 

‘Effective management of messes requires planning, not problem 
solving . ... Planning and design are predominantly synthesizing, rather 
than analytic, activities; they involve putting things together rather than 
taking them apart. Moreover there is no such thing as an optimal plan 
for, or design of a purposeful system in a dynamic environment. The 
objective of such efforts should be to produce systems that can pur- 
sue ideals effectively and in a way that provides continuing satisfac- 
tion to the participants.’ 


Just as the classical methods of systems analysis have lost their way in the jungle 
of planning systems, so have the classical dogmas of OR! The remarkable thing is 
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that having entered the maze with totally different prejudices, practitioners of both 
disciplines are reaching very similar conclusions about what needs to be done. To 
see why this is, I first want to talk a little bit more about the maze; how they got 
into it, and why something rather strange may happen in the middle! See Figure 2.1. 

It seems to me that any computer system can be characterized by two main vari- 
ables - size and complexity - and that by using these as the axes of a graph one can 
effectively map the traditional domains of Operational Research and Systems Ana- 
lysis. So, up in the top left of Figure 2.1 we have classical OR, where tiny amounts 
of data are subjected to incredibly clever algorithms. Possibly an extreme example 
is a program I wrote a few years ago which works out the best pallet-layout for a 
box of a given size. The data input is literally three numbers; the program is over 
500 lines of pretty terse PL/1! More typical might be the well known ‘travelling 
salesman’ problem, where the data consists simply of the coordinates of 40 or 50 
calls; the programs to find the salesman’s best route form a specialized branch 
even within OR! 

So to the other end of the chart, wherein reside the thundering great DP systems 
beloved of the systems analyst. Mounds and mounds of data to be channelled 
through an easily defined sequence of nice, simple processes. To see what happens 
in the middle, I want to redraw Figure 2.1 in three dimensions, plotting vertically 
the transition from the systematic approach of the systems man to the analytical 
approach of the OR man (Figure 2.2). 

The first, and most obvious question is: why have I drawn the surface with a 
fold? Again it’s a subjective view, but I believe that for medium-size, reasonably 
complex ‘messes’ there is no middle ground. To see why, I’m going to start with a 
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Figure 2.2 


rather trivial example: how would each discipline design a system to play noughts 
and crosses (tic-tac-toe)? The analogue to the OR approach would be to take the 


position as it stood, e.g. | 
X 
X 


and to use a set of rules to work out where to play next. This would use a tiny amount 
of storage (basically nine numbers), and a pretty small, but by no means insignifi- 
cant, amount of program. 

The analogue to the systems approach would simply be to store all the possible 
games of noughts and crosses, and to flag any positions which were known to lead 
to a loss. The program to avoid these positions is trivial, and for such a small game 
no vast amount of storage would be needed either (there are only 77 distinct 
nought-has-won positions). From noughts and crosses we could move one of two 
ways: up into games with increasingly complex rules but still with rather low 
subtlety (e.g. boxed board games); or across into very large games with very simple 
rules (e.g. the Japanese game of Go). Now no one has yet solved Go, but there is 
no reason in principle why it should not be done. It’s just that in practice the total 
number of possible games vastly exceeds the capacity of any conceivable computer 
memory! No, the real conceptual problem is the games that fall slap in the middle, 
chess being the classic example. Again it’s too big to solve by brute force, but it’s 
also complex enough that one cannot set any hard and fast rules which will select 
the ‘best’? move in any position. In other words it cannot be tackled either from the 
OR or from the systems viewpoint! The way such games are being approached is, 
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I believe, very instructive when it comes to systems for ‘managing messes’. To play 
a reasonable game of chess a computer must have a dictionary of patterns (not of 
positions), a strategy based on advice (not particular moves), and a set of goals 
towards which the advice should eventually lead it. Now there is no doubt that 
many computers play more than just a reasonable game of chess, so why can’t this 
approach be tried with the analogue to such games, i.e. the systems for planning 
and information? 

The key lies in the fact that, unlike systems which play chess, planning systems 
must deal with a changing world; in particular the goals that they are seeking rarely 
stay constant for long. The OR approach, which is to make the model ever more 
complex, will always lag behind the problem it is trying to solve; the systems 
approach will be swamped by its own data. 

To illustrate the point, I want to take another analogy, I hope not too far 
fetched: suppose military power A wants to drop something nasty on a target deep 
in the territory of military power B. 

The OR solution is essentially ballistic: a complex model of the flight-path is 
devised, a solution (i.e. trajectory) is computed, the missile is pointed in the right 
direction and fired. At the opposite extreme is the cruise missile, which is provided 
with a detailed map of a narrow corridor of enemy terrain, and sent out to find its 
way along this. The OR method is clearly vulnerable to the unexpected, e.g. a sud- 
den thunderstorm in its flight-path, but, more to the point, neither alternative has a 
hope of hitting a moving target! The only way to do that is to send in a piloted air- 
craft with some reasonably good maps, a decent navigation system, and a pilot who 
understands the target’s behaviour. If, for ‘navigation’ and ‘maps’ you read ‘plan- 
ning’ and ‘information’, then the analogy is complete. What is clear is that how- 
ever accurate the trajectory of the ballistic (OR) approach, and however detailed 
the map of the cruise (systems) approach, there are some targets that neither will 
reach. To hit these you must abandon both methods, and should concentrate your 
efforts on developing good maps and sophisticated aids to navigation, and on 
training your pilots to use them. 

What it all comes down to is that we still need people: people with the experi- 
ence to perceive the patterns, with the expertise to use the advice, with the sensi- 
tivity to adapt to a changing world. Because we (the analysts) are in the business 
of providing tools for such people to use, we must first understand how their job 
is done before we can even begin. The trouble is that the tools we provide will 
radically change the job, and the tool users must be given time to adapt before they 
can start to suggest improvements. Impasse! Such systems cannot be broken down 
into problems which the OR man can analyse; all we can do is to start somewhere 
and let the system grow. 

To look at the same thing from another viewpoint: both classical OR and stan- 
dard analysis aim to produce systems which will replace man as a decision-taker. 
In the pallet-layout example I quoted earlier, the object of the exercise was to pro- 
duce layouts which were better than those issued by the company’s product devel- 
opment department. In such diverse areas as inventory control and payroll, com- 
puter systems have taken over from people as the authority which determines when 
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orders are sent out, and when wages are paid. Much publicity is occasioned when 
either approach fails, but there is no doubt that for the two extremes (complex 
data/simple process; simple data/complex process) computers can and do replace 
people effectively. It is into the much more woolly areas of planning and control 
that computer technology is spreading, and here the emphasis is on decision sup- 
port, not decision taking. 

The system takes care of the routine tasks, and presents the planner with infor- 
mation in the way best calculated to help him use his subjective judgment. This 
both gives him more time to deal with the frequent minor crises, and improves the 
chance that he will act correctly to resolve them. Surely it must by now be self- 
evident that a system such as this cannot be designed from scratch. Even the 
obvious first stage of automating the more straightforward of the planning tasks 
will radically alter the planner’s approach to his job. Any attempt to define his 
information needs in detail must wait until he has adjusted his way of working to 
take advantage of Stage 1. Even then, the process is largely one of trial and error, 
of trying out prototypes and following up promising leads. 

There I rest my case for evolutionary design. I hope I haven’t given the impres- 
sion that it is a sort of fall-back, to be used when all else fails; it has a lot of other 
points in its favour, and I shall try to list a few of them. First, there’s the psycholo- 
gical benefit for the user; people really do care about the systems that form such a 
big part of their working lives. What better way to fulfil this need than to involve 
them in the design — possibly even in the programming - of the system right from 
the start? Secondly, an evolving system will start to pay back its costs almost 
immediately. In stringent economic times companies just cannot afford a two-year 
time lapse before a new system begins to pay its way. Thirdly, you simply get 
better systems! I know that’s little more than a personal statement of faith, but I 
hope the rest of this chapter has provided enough argument to convince those 
who treat such bold claims with justified scepticism. 

In summary then, when faced with a complex tangle of problems in a changing 
world the analyst has only one realistic choice: evolution. Later on I want to 
develop the methodology of evolutionary design a lot further, but before that I 
must take some time off to talk about APL. I want to say why I think APL is par- 
ticularly appropriate to this sort of system, and to give some hints on how it should 
be written if its unique characteristics are to be used to best advantage. 


Chapter 3 
Why APL? 


Just what is so special about APL? Why is it that gatherings of APL devotees have 
an atmosphere akin to religious revival meetings? On the other hand why do many 
DP managers view ‘in-house’ APL with such deep suspicion, and is there any basis 
for their fears? These are the sort of questions I want to look at in this chapter, I 
hope dispassionately! First, Pll take some of APL’s strong points, in particular 
those most relevant to the evolutionary approach. Then I must restore the balance 
by admitting to some of the problems you may well encounter. Finally, for those 
= who decide that APL really is for them - some of the pros and cons in the ‘bureau 
versus in-house’ debate. 

APL gives the programmer two tools which no traditional language can offer: a 
working environment in which program and data co-exist on an equal footing; and 
a consistent and powerful notation with which to manipulate them. Most planning 
(and many information) systems fall in the middle ground where the interaction 
between programs and data can be extremely complex; APL, with its ‘workspace’ 
concept, makes light of the subtlest interdependencies. 

This interchangeability of programs and data can be immensely helpful when 
you are first putting an application together; for example you might start with 


SALESPLAN¢?10 12,9100 


and use these randomly generated figures to test a series of functions in a production 
scheduling system. When the algorithm is working to your satisfaction, you want to 
switch to the real figures which are stored externally on a file. To do this, you 
simply define a function: 


SALES*¢SALESPLAN 


[1] aREAD SALES DATA FROM FILE. 


C2) SALES¢ ....... 
y 


and all your planning functions will continue to execute as if nothing had happened. 

Planning systems also tend to need a fair amount of abstract modelling, which is 
just what ‘Iverson’s Notation’ was designed for. Before this ever became APL it was 
in use the world over as aconcise, consistent way of expressing technical algorithms. 
The first APL interpreters simply relieved the early practitioners of the burden of 
translating their algorithms into a conventional language! I can’t resist throwing in 
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an example from my own experience: my problem was a subroutine to take a 
string of numbers and return the same list shuffled. In PL/1 (I won’t bore you with 
the gory details) this took a couple of loops and 22 statements; in APL the whole 
thing collapsed into 


RESULT¢LIST[ (pLIST)?pLISTJ 


Can you wonder that I haven’t written much PL/1 since?! 

The sheer conciseness of APL has the additional advantage that it simply takes 
less time to code it, and this can be important when you’re changing a program 
with the user at your elbow. In fact it makes the whole business of ‘programming 
by negotiation’ (of which more in Chapter 6) feasible. The fact that APLis genuinely 
interactive helps too; to be able to alter programs ‘in flight’, and to try out bits of 
code at the terminal, is an enormous boon when you need results quickly. Add to 
this APL’s superbly general functional structure, its steadily improving file-handling 
and its recent acquisition of full-screen management, and the question becomes 
‘why not APL?’. 

Having spent a page or so extolling the virtues of APL, I must now restore the 
balance by admitting to a few of the drawbacks. Once again the problem lies in 
trading off the cost of hardware against software, but the balance is by no means as 
clear-cut as it first appears. Efficiency is one of the more contentious issues; many 
DP departments still live in fear of a couple of APL terminals bringing the whole 
system to a grinding halt. They are often right, but for all the wrong reasons! The 
myth goes that interpreters are slower than compilers, therefore APL (being inter- 
preted) will take more CPU to do the same job than, say, FORTRAN. For normal 
computer languages the conclusion holds, but (as I keep saying) APL is not a 
normal computer language. It has an enormously powerful syntax, but the only 
symbols which may change the order in which code is executed are ‘>’ and ‘()’. 
This makes the job of turning a line of APL into machine code relatively straight- 
forward; and, because each operator does a clearly defined job, that machine code 
can be optimized so that it runs very fast indeed. What can slow APL down is its 
dynamic management of storage; this may sometimes be a severe burden, but it is 
hardly a direct result of interpretation! In fact, as interpreters get steadily cleverer, 
even this is becoming much less of a handicap in the comparison with conventional 
languages. My experience is that a well thought out, well written APL system will 
use just about the same amount of machine resource, on average, as the same 
system written in a conventional language. 

The reason for this is straightforward enough: every time a PL/1 program is 
changed, however trivially, at least a substantial chunk of it must be recompiled. In 
APL, on the other hand, the only parts of the program the interpreter sees are the 
bits that are actually in use! Vast tracts of code, usually error routines and the 
like, may never get interpreted at all once the system has gone ‘live’. Consequently, 
it doesn’t take a particularly high inflow of minor changes to leave the APL system 
ahead in the CPU stakes, and APL systems have been justified on the CPU savings 
alone. Even leaving this point aside, it is quite possible to concoct tests whereby an 
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APL function will perform the same task faster than compiled, optimized PL/1! 
Not remotely typical, I know, but intriguing all the same. 

Of course the ‘machine costs’ of a system are declining rapidly in comparison 
with the ‘people costs’, and one of the joys of APL is that it gives a system manager 
some control over where the balance is to be struck. This choice again arises from 
APL’s ability to regard programs as data, and vice versa. You can create a whole 
range of software aids, written in APL, to help you with the development, main- 
tenance, and documentation of your APL systems. Examples would include full- 
screen function editing, global search-and-replace for a given name, automatic 
production of function listings, and cross-reference tables. Such aids, particularly 
the ‘document’ functions, contribute large savings in programmer time, but tend to 
make correspondingly heavy demands on the CPU. By regulating their use (e.g. 
workspace documentation only after 5.00 p.m. or during the lunch hour), an APL 
installation can effectively ‘fine-tune’ the trade-off between its programmers and 
its hardware. 

Why then have I said that DP departments are right to be afraid of APL? I can 
find two of the answers in the discussion above: the key phrases are ‘well written’ 
and ‘on average’. It is very hard indeed to write FORTRAN or PL/I sufficiently 
badly to produce any noticeable drop in efficiency; the same is not true of APL, 
where two different ways of coding the same problem may easily differ in speed by 
a factor of a hundred! For example, both the expressions below will take a numeric 
vector and turn it into a one-column matrix: 


V<+1000010 
M«((pV),1) eV 2 ms 
MeVo .+,0 115 ms 


Possibly an extreme example, but on the face of it there is absolutely nothing 
wrong with the second expression; it just happens to take 50 times as long as the 
first! An interesting piece of evidence for the dangers of thoughtless programming 
comes from a recent IBM research report (Waldbaum, 1978). This includes several 
fascinating case studies of desperately (and unnecessarily) inefficient programs, but 
from my point of view the most interesting figures are the percentages of users 
who managed to absorb half of the prime-shift CPU time. On OS it took around 
4% of the users to consume 50% of the available CPU; on VM/370 between 3% and 
4%; on APLSV the figure was 1%! Aberrant behaviour in APL can cause far more 
damage to a computer system than the grossest misuse of conventional language. 
Having accepted that inefficiently written APL can consume far more than its 
fair share of precious CPU - what’s wrong with good APL? The problem lies in the 
nature of the load that a typical clutch of APL applications creates. Today’s big 
mainframes tend to be built around the traditional batch job stream: a job comes 
in, occupies an area of storage which doesn’t fluctuate too much, takes a steady 
ration of the CPU cycles, and goes away, only to be replaced by another job of 
largely similar characteristics. Throw ina couple of APL systems, and this pleasantly 
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ordered flow may develop some rather drastic turbulence! It’s not that the APL 
load per se is particularly heavy, it’s just rather difficult to mix it sensibly with an 
existing batch schedule. 

DP trepidation at the idea of a mixed batch-APL load is not without foundation 
after all! 

So far all the discussion is this chapter has assumed that there is a simple choice 
between an APL system and a system written along conventional lines. Of course 
life is rarely as simple as that; most companies already have an enormous invest- 
ment in conventionally structured data. Whether sequential, random access or data- 
base, such data is always designed to be used an element at a time; if this is to be 
accessed by an APL system there are two ways of doing it, but neither is particu- 
larly satisfactory. For example, suppose APL is being considered for a system to 
query a company’s personnel records. At first sight it is the ideal vehicle for such a 
system: to answer questions like 


= AVERAGE SALARY WHERE AGE>35 


all that is needed is a couple of APL vectors (SALARY and AGE) and two one- 
line functions (AVERAGE and WHERE). The problem is in creating these vectors; 
Figure 3.1 shows what I mean. 


Conventional data format 


Employee Salary Age 
2501 10005 46 
2503 7896 27 
2504 12487 51 
APL data format 

Employee ... ... .. 25012503 2504 

Salary wee vee eee 10005 7896 12487 

Age es. “aes ek 46 27 51 

Figure 3.1 


The first possibility is to forgo the elegance of parallel processing and to use 
APL to read the conventional file a record at a time. If the company had no more 
than a few hundred employees this might be a reasonable way out; more than this 
and the overhead of interpreting the same piece of code several thousand times 
becomes too severe. The other approach is to design a batch conversion program 
which effectively ‘inverts’ the personnel file. 

Of course this is rather wasteful of storage and the file inversion may take a 
significant amount of CPU time, but it does leave the data in a format which APL 
can process very efficiently. (The subject of file inversion does get a section to 
itself later on in Chapter 12.) This method only really makes sense for quite slow- 
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moving data; weekly or even monthly inversions may suffice for the personnel 
system, but the prospect of daily inversions of more volatile data is not one that 
the DP department will view with pleasure. 

I hope this chapter has demonstrated that there is often no clear-cut answer to 
the question ‘why APL?’. It is a problem-solving tool of quite unique capabilities, 
but it is not the answer to everything. As a summary of a few of the pros and cons, 


here are some candidates for the APL approach, with comments on each. 


System 
A quick ‘one-off’ 


A complex file- 
query system 


A complex planning 
job which uses little 
or no external data 


Any prototype system 


A large and repetitive 
data-cruncher, e.g. 
payroll, simulation, 
linear programming 


Why APL 


Will get results 
in days rather 
than weeks 


Query language is 
easy to build and 
quick to modify 


Faster, more concise, 
and more flexible 
than any conven- 
tional language 


Gets the bugs out 
of the design at 
very little cost; 

can be used as the 
specification for the 
real system 


May be the only way 
to get something off 
the ground fast 
enough 


Why not APL 


May be rather expensive, and 
‘one-offs’ have a nasty habit 
of becoming permanent 


Overhead of inversion; 
limit of workspace size 


May cause system program- 
mers a few headaches 


Again there is a danger of it 
becoming permanent 


Very expensive 


You can, of course, bypass many of the problems by running your APL system 
on a time-sharing bureau; this is certainly one of the commonest ways to get 
started. Many companies move their APL in-house sooner or later, simply on the 


grounds of cost, but doing your work over the phone line does have its advantages 


for example: 


2 


@ The service is usually guaranteed 24 hours a day, seven days a week. Bureaux 
live or die by response times; this may well be better than an in-house service 


will give. 


@ The communications are done for you; if you have a couple of hundred 
branch offices around the world it is very handy to let them share a common 
database for the cost of a telephone call to the nearest node in the bureau’s 


network. 


@ Most bureaux leave lots of useful data/utility functions lying around for you 
to use. They also provide ‘free’ advice (and education) for novice users. 
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@ The APL itself may be better - APL,PLUS is rather more powerful than 
anything IBM currently offer. However, this is rather a double-edged sword - 
stay too long on the bureau and it may be very difficult to break away! 


Why, then, run APL in-house? Cost is one reason I’ve already mentioned; some 
others are as follows: 


@ The considerable hassle of proofing all your systems against ‘line-drops’. 
Even if a total loss of telephone line is uncommon, there is nothing more 
irritating to a user than a sudden splurge of noise in the middle of an other- 
wise neat report. 


@ Sooner or later you'll want to get at company data with your APL system. 
Copying the relevant files to tape and shipping them to the bureau is rarely a 
satisfactory solution; there is just too much scope for administrative error! 


@ Many users insist that their data is too sensitive to be allowed off the premises 
anyway. 


@ APL is moving rapidly from the teletype age into the VDU age. Even over a 
good leased line, much of the advantage of the screen may be lost when it is 
used remotely. However, as line speeds increase, and VDUs get cleverer, this 
problem could recede quite quickly. 


All of which assumes that you want to use APL in the first place! I hope this 
chapter has at least gone some way towards answering the questions I posed at the 
start. I hope also that I have pointed out some of the problems you may find, 
whether you run your APL on your own computer or decide to use a time-sharing 
bureau. Whichever you choose, if you have found a satisfactory answer to ‘Why 
APL?’ then the next logical question is ‘How?’. The answer to that one forms the 
rest of this book. 


Chapter 4 


Structure and style in APL 


This is not in any way, shape, or form an attempt to lay down standards; better 
men than I have perished in that mine-field. Instead I have assembled a collection of 
advice, anecdotes, and examples which you can take or leave as you wish. The 
material is not laid out in any particular order, but I have tried to make each sec- 
tion as self-contained as possible. The topics covered in this chapter are: 


Aims and objectives 

Idioms in APL 

Linking functions together 

Useful ways of doing nothing 

To loop or not to loop 

Recursed! 

The user’s view: closed versus open systems 
How much code on one line? 

Zero-origin - pros and cons 

Ways of branching, and IF functions 

Some thoughts on structured programming 
Ways of looping, if you have to 


In general, I have tried to suppress personal prejudices; I hope the text makes it 
reasonably clear where I have failed! 


Aims and Objectives 


To what should the APL programmer aspire? To the most elegant use of the 
language? To the most efficient code? To the most flexible and easily maintained 
system? Perhaps just to get results in the shortest possible time?! It all depends on 
the context, who is to use the programs and how. Let me take the four aspirations 
above, and try to give a context for each. 

To make the most elegant use of the language. Always valid, but not at the ex- 
pense of the other three. Elegance must be a personal judgment, and your ‘elegant’ 
code may not happen to be the most efficient, flexible, or fastest to write. If it is, 
you are lucky indeed, and this section need trouble you no further! 

To the most efficient code. Efficient in what sense -in its use of you or the 
machine? Probably the latter for utility functions which are heavily used and rarely 
altered; more likely the former for the top-level functions which will change con- 
stantly. 
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To the most flexible and easily maintained system. Yes, but don’t spend too 
long designing it. This may conflict with efficiency too, especially in storing data. 

To get the thing done. Political necessity is often enough to leave this the sole 
criterion by which the programmer is judged. 


Idioms in APL 


‘It’s raining cats and dogs!’ we might exclaim (in Britain anyway!), meaning that 
rain is presently falling unusually heavily. No one actually reads the individual 
words in an idiom like that - the meaning is implicit in the phrase as a whole. 
Whether you are ‘getting on like a house on fire’ or preparing to ‘turn over a new 
leaf’, you certainly don’t expect your listeners to take such phrases apart to appre- 
ciate their full meaning. On the contrary, much of the meaning may be lost if this 
is done! 
APL is full of such idioms, and the same rules apply; for example 


VCAV] 


is not understood any better by taking it apart. On the contrary, it is very easy to 
appreciate ‘sort V’, whereas ‘index V by its ascending grade’ makes far less sense. 
The beauty of an idiomatic approach to APL is that once an idiom is learned it can 
be remembered thereafter as a unit, and recognized as such by others. Another 
example might be 


<\bit vector 


to leave only the left-most ‘ switched on. The idiom ‘<V is read as ’first occur- 
rence of ...’” and should be taught as such; the details of how it actually achieves 
this result merely confuse the issue! 

There is, of course, one interesting sideline on the subject of idioms - dialect! 
If a Yorkshireman tells his wife that he ‘won’t be back while 9.00’ he will be 
readily enough understood, and his supper will be on the table at 9.05. To anyone 
unfamiliar with this highly local usage of ‘while’ to mean ‘until’, the sentence is 
totally confusing. The same might well come to apply in APL, as the same basic 
language elements are put together in different ways by different groups of pro- 
grammers. For example to strip trailing blanks from a character-string one might 
one day come across 


STRING+(6V\OSTRING#' ')/STRING 
and on another day 

STRING¢(1-(STRING=! ')11)+STRING 
Both versions are equally valid and each will be read with equal facility as ‘chop off 
trailing blanks’ by their respective programmers. The problems, as with the York- 
shire ‘while’, come when one is faced with a program written in a very unfamiliar 


dialect. If you can’t read the idioms, then trying to find out what a piece of APL 
code does really is no fun at all. 
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I suspect that the development of idioms is still at quite an early stage in the 
APL community; after all the notation has only been around for 10 years or so. 
However, there are already some nice examples of what one might call ‘compound 
idioms’. For example, to remove duplicates from a vector one might use 


VEC+(1 1 & <\VECe.=VEC)/VEC 
This uses three idioms in all: 
<\ we have already met 
118 major diagonal 
VEC+(..condition) /VEC sieve on given condition 
to achieve the final idiom ‘remove duplicates’. Of course you may also see 
VEC+( (VEC 1VEC ) =i pVEC ) / VEC 


and I’m sure there are many others! 
For those of you who would like to see more of the idioms in current usage, 
there is a much more extensive collection in Chapter 8. 


Linking Functions Together 


Excluding clever things with shared variables, there are two basic ways of doing 
this. 


Pseudo-primitives 


These are functions which behave exactly like the APL symbols, i.e. they take one 
or two arguments and they return one result. They have no other effect on the 
environment whatsoever. Because they behave like the APL symbols, they can be 
strung together in the same way and the APL interpreter will sort out the syntax. 
For example 


(ARJUST AALPHSORT ',' ATAB 'FRED,JOE,HARRY'),!!! 


FRED! 
HARRY! 
JOE! 


(See Chapter 8 for the functions ARJUST, AALPHSORT and ATAB.) 
Note that the following is not a pseudo-primitive: 


R¢A PLUS B 
[1] R+eA+B 
[2] AFLG<1 
y 


Line 2 disqualifies it! 
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Communication via global variables 


This is common among the higher-level functions, since users may get confused by 
complex syntax, arguments and results. For example: 


UPDATE 
REPORT 










SIGNOFF 






Y 
CALCULATE 


The user never sees AFLG, so he won’t get confused, but he won’t understand 
either, so he may beat the system by doing things in the wrong order! This approach 
also makes the system harder to maintain, because no state-using function can be 
fully understood without reference to all the state-setting functions. Moral: try for 
pseudo-primitives where you can; resort to globals where you must. 


Useful Ways of Doing Nothing 
Some typical ways of doing nothing: 


VAR¢VAR+0 
VAR+VARx 1 
VAR¢O[ VAR (VAR is positive) 


VAR¢VAR,!! (VAR is a character vector) 


gitt 


How can these be used to advantage? Here are a few examples. 


@ Add 1 to score if answer is right: 
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SCORE+SCORE+ANSWER=RIGHT 
@ Set all negative values in list to zero: 
LIST+OfLIST 


@ Pad character matrix with blanks to make it at least five columns wide. If it is 
wider anyway, leave it as it is: 


MAT<(0 Sf pMAT)+MAT 


è Display the message ‘ADDITIONS TO FILE’, unless the new item is a dupli- 
cate, in which case display ‘ADDITIONS TO FILE; ITEM ALREADY ON 
FILE: 


tADDITIONS TO FILE' ,DUP/' : ITEM IS ALREADY ON FILE! 


@ Call new page routine if line count exceeds 65: 
¢(LINECT>65)/'LINECT¢ANEWPAGE PC+PC+1! 


There are many more examples, but these probably illustrate the point well enough. 
You can avoid an awful lot of branching by cunning use of ‘null operations’; this is 
usually more efficient and, by almost any standards, more elegant. Don’t get carried 
away though; if the choice is between one branch and multiplying ten thousand 
numbers by onethen take the branch! Another counter-example is in menu-selections: 


OPTION<AVALIN'ENTER CHOICE (1 TO 9) :- ! 


e Method 1 


9(L1,L2,....)COPTION] 
L1:REPORT1 

EXIT 
L2:REPORT2 

+EXIT 


etc. 


@ Method 2 


2 (OPTION=1)/'REPORT1'! 
¢ (OPTION=2)/'REPORT2' 


etc. 


Method 2 may look a lot neater, but it is less efficient. Executing nothing eight 
times takes a lot longer than a couple of jumps! Of course if all the sub-functions are 
‘REPORT’ suffixed by the option number, then 


2'REPORT! , FOPTION 


is the best of the lot. 

Note that all these ways round branching rather give the lie to the idea that flow- 
charts are language-independent. In APL a flowchart is usually just a vertically con- 
nected series of boxes! 
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One final thought on branch avoidance is to define ‘null functions’, e.g. 


RFLG FN VALUE 


[1] aDOES NOTHING IF FLG IS ZERO 


[2] ReVALUE 
[3] >FLG+0 
CAT. oaren eteni etc. 


This buries the branch inside FN, so that when it is called the code might look like 


FIGS¢(ASK'CHECK THE DATA ?') FN AREADIT 'DATAFILE! 


which looks much clearer than the alternative of branching round FN if the answer 
is ‘NO’. 


To Loop or Not to Loop? 

On the face of it a silly question. The interpretive overhead goes through the roof 
when looping code is executed. There are, however, times when looping can be 
more efficient; a classic example is in string searching. (Those of you lucky enough 
to use a version of APL with a OSS function can ignore the next bit.) The sledge- 
hammer approach, 


POS«(A/#(0,1 1+9SUB)$SUBe .=TARGET) /1pTARGET 


makes all possible matches of SUB against TARGET. Apart from the ever-present 
danger of WS FULL, most of these matches are unnecessary. The rather sophisti- 
cated ASS (see Chapter 8 for a listing) does loop, but can be several hundred times 
faster. It starts by looking for the character in SUB least likely to be found in 
TARGET, then only a few characters in TARGET (those in the right relative 
positions) need to be checked for the next least likely character, and so on. The 
extra work done by the interpreter is more than made up for by the saving in 
execution time. 

The other time to loop is when the closed-form version is so complex or obscure 
that it takes half a day to get it working. This sort of mental effort is probably only 
justified for system utilities which are in very common use; otherwise it just isn’t 
worth it. Remember: you are a more important resource than the computer! 


Recursed! 
What is it about recursion that makes me want to hide in a corner and whimper? 
Somehow the idea of a function: calling itself, calling itself... , and so on; then 
unwinding; then doing it again; eventually to emerge triumphant from its own 
intestines - is enough to give anyone the creeps! 

There is all the difference in the world between when you can use recursion, and 
when you should: 
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è You can use it when you need to solve a problem which breaks down natur- 
ally into a series of smaller problems which look just like the big one. The 
process will continue until one of the smaller problems is trivial, when the 
whole process will go into reverse, and the recursion will unwind. 


@ You should use it when it is necessary for one of the sub-problems to refer 
back to the result of a previous step in the chain. This is very rare, except in 
some decidedly off-beat mathematics. 


For an example of recursion in full flight see Chapter 10; for the moment I want 
to confine myself to a simple example which could equally (and more efficiently) 
have been defined with looping. 

To add two binary numbers, using ‘not equivalent’ and ‘carry’: 


ZA ADDER B;C 


C1] aBINARY ADDITION FROM FIRST PRINCIPLES. 
[2] Z¢A+B 
(3) +(V/C+AAB)+0 


[4] 2Z+Z ADDER 1+C,0 
y 


The User’s View: Closed versus Open Systems 


Closed 


DRIVER PROGRAM 





In a closed system, the user is always under control. He is given a choice of options, 
and may select only from those offered. Consequently he will never do anything 
silly, because you never give him the chance. 

In an open system an initial WELCOME function releases the user straight back 
into APL. He can then use any of the functions available to him in any sequence 
whatsoever. (Of course WELCOME may set a flag somewhere to debar access to 
certain functions.) This approach has two main advantages over the closed system: 
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it allows the user to adapt his way of working without causing any programming 
changes; and it greatly reduces the total amount of coding needed to get the appli- 
cation going. Driver functions tend to be pretty wordy and very tedious to write. 
The open system has the disadvantage that an over-adventurous user can get him- 
self into trouble, so the onus is on you to make sure he really understands the 
system. 

Even if you eventually intend a system to be closed, you should always start off 
with an open system, and write the driver last. 


How Much Code on One Line? 


Even without the diamond separator you can get an absurd amount of code on one 
APL line. The string search a couple of pages back is by no means an extreme 
example, and many APL programmers seem to regard ‘one-liners’ as the ultimate 
achievement. There seem to be two reasons for this: in some very early APLs 
functions were read from disk a line at a time and the one-liner was thus a very 
efficient animal; the second reason is the simple intellectual challenge. Writing a 
complex piece of code in as few lines as possible is just like solving a crossword 
puzzle; indeed obscure code for the sake of it is a common enough phenomenon in 
conventional languages. It’s just that APL gives the obscurantist more scope! 

On the other hand, code can be over-simplified. Suppose we want to replace 
all the underscores in a vector by blanks; which of the following two versions is 
clearer? This 


HITS¢VEC='_' 
LEN¢pVEC 
POS+HITS/1LEN 
VEC[POS]+! ! 


or this 


VECL(VEC=!_')/1ipVEC)]+! ! 


Moral: each line of code should perform one logical operation, of the sort of 
complexity you could describe easily in one sentence. A good guideline is that if a 
statement gets deeper than three levels of brackets it’s ripe for breaking up. 


Zero-origin - Pros and Cons 


Why have the option of counting from zero at all? I suspect that the main reason is 
historical: the early implementers of APL were all fluent assembler programmers, 
and assemblers all use zero-origin for things like memory offsets and table indices. 
Thus they often felt more comfortable counting 0, 1,2,...than 1, 2,3,...,s0 
they gave themselves the option of doing so in APL. Of course once it was there 
people found all sorts of elegant uses for it: for example to set a flag to ‘P’ or T’ 
in response to the question ‘PRODUCTION OR TRIAL?’ 
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ATRL¢'TP!('Pt=1+BAREIN' PRODUCTION OR TRIAL ? :- '] 


is rather neater in zero-origin. 
Also in graph-plotting, where you often end up with an array of zeros and ones, and 
want to display it, then 


GRAPH<«! *'(MAT] zero-Origin 
is a bit neater than 


GRAPH¢! *'(1+MAT] one-origin 


The encode/decode functions work much more neatly in zero-origin too. 

So much for the good points; now for some drawbacks. The first is that unless 
you are very sure of what you are doing zero-origin will sooner or later catch you 
out; for example a branch of the form 


>+LABX1A>B 


won’t go to LAB at all in zero-origin, it will terminate the function! 

The second reason is the overhead of making all your utility functions origin- 
independent. This more than makes up in messiness and obfuscation for all the 
elegance gained in the calling functions. Things like 


MAT+MAT,{OIO] LINE 


take up unnecessary CPU time and look rather horrid. Not to mention the fact that 
you will have to test them all twice; once in one-origin, once in zero-origin. Of 
course you could always localize the index-origin, and reset it within each utility. 
Again it’s messy, and again it wastes CPU time. 

My personal feeling is that zero-origin is better forgotten about, but perhaps 
that’s just because I find counting from zero a strange and unnatural habit! If you 
do use it, at least be aware of the problems. 


Ways of Branching, and Some IF Functions 


When it comes to conditional branching, APL provides the programmer with some- 


thing of an embarrassment of riches. Many of the methods rely on the facts that: 
(a) a branch to a null vector is not a branch at all; (b) any arithmetic operation with 
a null vector is itself a null vector. For example 


+LABEL[ 1A>B 
+LABELx1A>B 
Others use compression to produce the desired null result: 


+(A>B)/LABEL 
>((A>B) ,(A<B) ,1)/GT,LT,EQ 


This also relies on the fact that a branch to a vector (e.g. 5 6 7) in fact goes to the 
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first label in the vector. Thus the conditions need not be mutually exclusive; if two 
or more are true, then the left-most is the one that determines the branch point. 
This useful fact is also exploited in branch instructions such as 


>( ..expression.. )$L1,L2,1L3 


Another property which comes in useful is the behaviour of take and drop on 
labels. The four possibilities are: 


( ..positive number.. )*ZAB LAB, 0 0 etc. 
( ..ZERO .. )+LAB null vector 

( ..non-zero number.. )+VZLAB null vector 

( ..ZERO .. )+ LAB LAB 


which gives the very neat pairing of 


>( ..expression.. )*ZLABEL branch if 
+( ..expression.. )+LABEL branch if not 


Note that the expression may evaluate to zero or one, in which case the first of 
these behaves identically to 


+( ..condition.. )/LABEL 


However, the version using take seems to be fractionally faster on most APL 
systems. (See Table 4.1 for the exact figures.) 


Table 4.1 Relative times of some branch methods 








Statement Time for 100 executions (ms) 
+8 1.2 

>LAB 4.2 

C4 LAB 10 

+C/LAB 12 

+LABxiC 17 

>LABI[ iC 17 

>LAB IF C 25 

+LAB WHEN C 55 





All the timings were on an IBM 3032, running VS APL under VSPC. 
For comparison: 

A 1.1 ms 

20/'ABCDE'18 ms 


Finally, of course, there is nothing to stop you burying any of these in a function, 
and calling it IF. You can then write 


>LABEL IF A>B 
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which must be the most readable of the lot. The simplest form of such functions is 
just 
R+LAB IF COND 


[1] R+«¢COND*LAB 
v 


Another possibility is a function with the following properties: 


>LAB WHEN COND true goes to LAB 
false no branch 

+(L1,L2) WHEN COND true goes to L1 
false goes to L2 

+(£1,L2) WHEN (COND1) ,COND2 L1, L2, or no branch 


+(L1,L2,L3) WHEN (COND1),conD2 L1, L2, or L3 if neither 


etc., for as many labels as you like. 

The second example has the great advantage of stating both branch points 
explicitly. Even if one is redundant, this can add dramatically to the clarity of the 
code. Incidentally, a similar convention was used in some very early FORTRANS 
where the conditional statement was 


IF (A>B) 12 


which branched to 2 if the condition was true, otherwise to 1. 
Anyway, if you want to use ‘WHEN’, here it is: 


R¢LAB WHEN COND 


[1] R+¢(~(pLAB)+COND=0)/LAB 
v 


Happy branching! 


Some Thoughts on Structured Programming 


The ‘GOTO’, it is often said, is the bane of the structured programmer’s life. How 
then dare I raise the subject in a book about APL, which knows no other way? 
First, I would like to take issue with those who say that GOTOs, of themselves, 
lead to ‘spaghetti programs’; such code is the consequence of one thing only - 
bad programming. What is true is that by banning GOTOs a language designer can 
make it virtually impossible for you to write really convoluted code. In APL no 
such safeguard exists, and the responsibility remains with the programmer; branches 
round branches - this is the horror that the structured language keeps you from and 
that you must consciously avoid in APL! 

In theory you should be able to break down any programming task into some 
combination of only three basic forms: 
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\) 





END END 


Sequential Alternative Iterative 


In APL sequential is obviously the default; unless we do something to stop it line 
5 will follow line 4 and line 6 will follow line 5. 
The alternative structure can very often be achieved without an actual branch 
instruction (see ‘Useful ways of doing nothing’); otherwise something like 
Condition’ Condition2 Condition 3 


ELSE 
PROCESS 1 | PROCESS 2 | PROCESS 3 | PROCESS 4 


+(L1,L2,L3,DEFLT) WHEN (CASE1),(CASE2) ,CASE3 
or 





SELECT... 






IF ORIF ORIF 





+((CASE1),(CASE2) ,(CASE3) ,1)/L1,L2,L3,DEFLT 
etc., represents this one neatly enough. Of course the ‘IF-~THEN’ is really only a 
subset of this: 


+(COND)+SKIP 
ACTION 
SKIP: 'READY! 


ACTION 


What about iterative structures? Clearly the most important thing is the way we 
escape from them, and there are three possible places to get out: the top, the 
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bottom, and somewhere in between. Here are the three types, represented both in 
flowchart and block diagram style: 


DO WHILE ... or ‘leading test’ loop 










Condition 


PROCESS 
PROCESS 


Condition 


Done 
PROCESS 
REPEAT UNTIL... or ‘trailing test’ loop 


PROCESS 












No 7 


CYCLE... or ‘central test’ loop 


i 


PROCESS 1 
Condition ? 
No 


PROCESS 2 





PROCESS 2 


I’m going to leave the details of how to code these until the next section, but the 
structures themselves make one point clear: the ‘REPEAT UNTIL’ will do PRO- 
CESS at least once, come what may, whereas the ‘DO WHILE’ can gracefully do 
nothing. 
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Finally, an example of how the CYCLE and CASE structures might come to- 
gether in an APL dialogue, this time in block-diagram form only: 


OPENING MESSAGE 


DISPLAY MENU 
READ COMMAND 
Command null? | 

No e Yes , 


First letter of command ? 
else 


CLOSING MESSAGE 













The APL code for this is 
DIALOGUE; LAB; CMD 

C1] ASAMPLE DIALOGUE FUNCTION 
[2] ‘UPDATE ROUTINE BEGINS! 
C3] LAB«ADD,DEL,CH,SKIP 
[4] MENU:>(pCMD*BAREIN 'ENTER NEXT OPTION :- ')+¥EXIT 
[5] >LAB['ADC!:ı14CMD] 
C6]  ADD:EDAADD 
[7] >SKIP 
C8]  DEL:EDADEL 
[9] +SKIP 


£10) CH:EDACH 

C11] SKIP:>¥ENU | 

[12] EXIT: 'END OF UPDATE ROUTINE! 
y 


This may look obvious, but it does illustrate one important point: the branches on 
lines 7 and 9 must go to the end of the CASE clause (i.e. SKIP), not back to the 
menu. I know it’s two branches instead of one, but it just isn’t worth compro- 
mising your principles to save that trivial an amount of CPU time! 
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Ways of Looping, if You Have To 


Having decided that a loop is necessary, how should the APL programmer go about 
coding it? As with simple branching there is a multitude of possibilities, but here we 
can apply some criteria to select the best way. My personal criteria are as follows: 


(a) It must be reasonably efficient. 


(b) The end of the loop must be clearly demarcated. The best language in this 
respect is probably BASIC, with its excellent 


10 FORI=1TON 
50 NEXTI 


(c) It must use a leading test, so that the equivalent of 


10 FORT=1 to0 
50 NEXT I 


never gets executed. 


Two structures which satisfy both (a) and (c) are 


LOOP1 N;CT 
C1] CT+0 
C2] L:>(N<CT¢CT+1 ) + EXIT 
[3] t PROCESS ',7CT 
C4) >L 


[5] EXIT:'READY' 


and 


C1] >*LAB+(NpL) ,EXIT,CT+1 
[2] L:'PROCESS ',+*CT 
C3] >LABCCT+CT+1] 


C4] EXIT: '*READY'! 
Vv 


I prefer the second version for two main reasons: it makes it clear that the end of 


the loop is not an ordinary branch, thus satisfying (b), and it is about 20% faster for 
loops of more than 20 or so iterations (see Table 4.2). 


Table 4.2 Relative timings of LOOP1 and LOOP2 


No. of iterations LOOP! (ms) LOOP? (ms) 
10 4 6 
50 15 13 
100 30 25 


1000 283 239 
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Often it is not even necessary to set up a counter; for example to process a work 
variable VEC an element at a time you could use 


some of VEC left 


VEC+0 , VEC 
LP:+( pVEC+1 + VEC) +DONE 
aPROCESS VEC[(1] 
+LP 
DONE: 'READY'! 


PROCESS VEC[1] 





If you ever find yourself writing a nested loop in APL, I strongly suggest you try 
to find another way of doing it. Either that or your next time-sharing bill is going 
to be a bit of a shock! 

I could happily ramble on through APL style for many pages more, but unfor- 
tunately style isn’t the only ingredient of successful APL; discipline is essential too, 
and it is to that subject that I turn next. However, the theme of style and structure 
does recur in Chapter 10, which includes several more examples of the block 
diagrams I have introduced here. 


Chapter 5 


Some coding conventions 


Just for once I’m going to be dogmatic. The benefits to be gained from a bit of 
coding standardization are so great that the tiny amount of effort needed to follow 
a few simple rules is repaid many times over. Whether you are an APL loner or a 
member of a vast development team this means you. Why standardize? Here are a 
few good reasons: 


(a) APL lays many traps for the unwary, some of them quite subtle ones. A few 
simple conventions and you will never stray near them. 


(b) Someone else (or yourself in a few years’ time) may actually be able to 
understand your programs. This could save a lot of good work from the 
scrap-heap. 


(c) You'll be safe from disaster when the system changes around you, or if you 
come in-house from a bureau. 


If you’ve been writing APL for a while, you must by now have your own view of 
what constitutes good coding practice. I hope you will read the rest of this for 
interest, but I would happily concede that your conventions are just as valid as 
mine. If you are quite new to APL, then I suggest that you follow the rules I give, 
at least to start with. Sooner or later you will inevitably need to break most of 
them, but at least by then you will know why you are breaking them, and you'll 
be well aware of the pitfalls they are designed to keep you away from. 

I want to start with naming conventions, because it is in the potential con- 
fusion of APL objects that the worst of the hazards lie. 


@ Rule 1. Always use mnemonic names for functions and variables. 


Function names tend to derive from verbs, variable names from nouns. Where a 
sub-function is essentially ‘local’ to its calling function (ie. it is not called from 
anywhere else, nor is it likely to be), preface its name with one or two characters 
from the name of the calling function. For example EDIT may call EDADISPLAY 
and EDAUPDATE, and by naming them thus you ensure that they are listed together 
by your documentation programs. Standard system utilities get ‘A’ as a preface, and 
should normally be locked, to ensure they don’t get listed. 


è Rule 2. Names of global variables should be prefaced with ‘A’. This identifies 
them clearly, and makes the job of tracking down any stray variables which 
should have been localized that much easier. Of course the corollary is that 
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names of local variables should not include characters other than ‘A-Z’ and 
‘1-9’. 


@ Rule 3. Labels should again be mnemonics, and should have the first letter 
underlined. Label variables should be underlined in their entirety, e.g. 


+LAB+( (pVAR)pLOOP) ,EXIT 


Of course LAB must be explicitly localized in the function header. Pedants note I 
have just broken Rule 2 as LAB is really just another local variable! 

Incidentally I have frequently come across recommended labelling schemes - 
such as ‘L1, L2,..., etc.’ or ‘A, B,C,..., etc.’ - in which the labels increment in 
some way as you move down the function. For languages like COBOL and FORTRAN 
this clearly makes sense, because in a program which runs to many pages it is vital 
to know roughly where a branch is going to. In APL (see Rule 7) it should always 
be possible to view an entire function at a glance, so the L1, L2,.. . convention 
adds nothing to the clarity of the listing. 

These three rules should steer you well clear of any potential name conflicts. As 
an example of the potential confusion that can arise when names clash, consider 
the following: 


UPDATE ; ROW 


C1] ACHANGE/DELETE TABLE ENTRIES 


C15] DELETE:UPDADEL ROW 


DELETE 


— ue w = = pe 


[1] aREMOVE LAST WEEKS FIGURES 


Just suppose that UPDATE gets suspended for some reason; then if the user 
types in ‘DELETE’ he will get the unlikely response ‘15’ and not a lot else! On a 
terminal or VDU without an APL keyboard this is not just embarrassing - it is a 
serious problem, and one which could so easily have been avoided. If you follow 
Rules 1-3 you leave open one potential conflict only: that between local variables 
and top-level functions. However, variable names tend to be noun-based and function 
names are derived from verbs, so this apparent flaw in the system is unlikely ever tp 
trouble you. I for one, would far rather live with it than resort to ‘WK1, WK2, . 
or some such for my local names. 
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That covers naming conventions. Now for something rather more controversial! 


@ Rule 4. Never use zero-origin, either globally or locally. The gain in elegance 
is minimal and the cost in future confusion considerable. 


Lovers of zero-origin should admit that they form a shrinking minority, and that 
their programs will one day be changed by someone who has never strayed from the 
safe ground of one-origin. They should also realize what a pest they are to anyone 
responsible for system utilities; zero-origin may be fun, but origin-independence 
most certainly is not! 

The next couple of rules deal with the way functions link together. 


@ Rule 5. Where possible, values should be passed in to functions as arguments, 
not allowed to float across in global variables. 


I can think of two exceptions to this one: 


(a) Where many arguments of different data types must be passed. Clearly the 
APL syntax allows for no more than two, and the process of stringing them 
all together outside the called function, then digging them out again inside, 
is highly tedious. 


(b) Where storage is at a premium. It will definitely pay not to double up the 
Storage taken by large objects, which is what some APL interpreters do 
when parameters are passed. 


If you are forced into using floating variables, please document the fact clearly 
in both the called and calling functions. 


@ Rule 6. Functions (except possibly right at the top level) should always 
return specific results. 


This applies particularly to utility functions which are to go on general release; 
it is not at all obvious to the author just how his creation might get incorporated 
into someone else’s system. A classic example of how not to do it is in the IBM 
distributed workspace PLOT. Suppose you have a routine called APR which prints 
character matrices on the line printer; you might think that you could type 


C1] APR 'HERE IS A GRAPH! 
[2] APR 20 60 PLOT ADATA 


- no chance! Because PLOT simply displays its output rather than returning it, all 
line 2 will achieve is a VALUE ERROR! 

In many ways arguments and results are like the knobs and sockets on the 
pieces of a jigsaw puzzle; without them there is no way of linking the pieces together. 

So far I have dealt mainly with ways and means of making your life easier 
during system development. If the system is definitely a one-off, or if it is purely 
for your own use, Rules 1-6 are probably enough to see you through. The rules 
that follow are designed to make life easier for those who come after you. 
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I have frequently seen the argument that APL programs are virtually unmain- 
tainable, even by the system author. It seems to me that the opposite is true; with 
good structuring and proper documentation an APL system can be maintained and 
modified far more easily than a program written in, say, FORTRAN. The key con- 
cept is that of ‘disposable code’; you should no more think of re-working an APL 
function than you would of attempting to repair an IC on a circuit board. If it 
doesn’t work, throw it away and get a new one. The philosophy of modular replace- 
ment is simple enough; to apply it in an APL system is quite straightforward, but 
again there are one or two conventions to follow. 


@ Rule 7. No function should be longer than one page, or about 40 statements. 


In a VDU system functions that fit on one screen are obviously preferable, but 
in practice a limit of 20 statements seems too restrictive. It merely encourages 
fanatics to cram yet more code on to each line! 

Three oft-encountered exceptions are as follows: 


(a) Functions such as ‘DESCRIBE’ or ‘HELP’. 
(b) Reporting functions where quite complex printer layouts must be set up. 


(c) System utilities such as workspace documentation or full-screen panel 
design. These are rather a special case, as they will be erased from the work- 
space before the system goes live. 


Leaving these aside, it would be hard to over-emphasize the benefits of breaking a 
system down into manageable modules. It will be easier to code, easier to test, and 
feasible to maintain. 


èe Rule 8. It should be possible to re-create any function from the comments 
alone. 


Of course APL is so rich in constructs that the new function may have very 
little resemblance to its predecessor; the point is that it will do exactly the same 
job when viewed from outside. This is more than just the usual plea to programmers 
to document their work; APL is hard to decipher and anyone who fails to comment 
adequately is placing a terrible burden on the shoulders of all who follow. Probably 
the two most important factors in favour of APL are the speed with which systems 
can be put together, and the ease with which they can be changed. To sacrifice the 
second of these in exchange for insignificant gains in the first really is the height of 
folly. Moral: write the comments first, then fill in the code. 


© Rule 9. Each function should do one clearly defined task. 


Functions which switch between several tasks depending on passed parameters 
are laying up trouble for the future. At this level, keep the structure almost child- 
ishly simple; coding tours de force should be safely tucked away in the lowest- 
level functions where they need never be seen again. 
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Before I close this chapter, there are a few minor points which are basically 
common-sense, but probably ought to be said: 


@ Never branch to line numbers, or to OLC +n. 


@ Use a standard branching method. I suggest take and drop (see Chapter 4) 
for if/if not. 


@ Don’t overdo the one-liner. In particular never use‘... ,0p...’, and beware 
of multiple assignments on the same line. 


@ Try to give each function a single exit point, i.e. use >EXIT, not >0. 


@ Only lock functions when it’s absolutely necessary. Before locking them clear 
out all comments and labels with a suitable utility. Be very careful not to lose 
the unlocked copy, for example by overwriting it with the locked version. 


@ If you copy and change a system utility, always re-name it. 


© Never use DAV explicitly. Sooner or later it will change under you; so put 
things like terminal control characters and graphics into ATC,AGR, etc., and 
index these. It won’t cost you anything, and it could save an awful lot of 
bother. 


© Bury things like file access and full-screen management in utility functions. 
Again this could save a great deal of trouble if you have to move your APL 
systems to a new environment. 


@ Retract and expunge shared variables as soon as you have finished with them. 


@ Always put something into OLX, even if only a one-line description of the 
workspace. 


I think that just about covers it. As I said at the start of this chapter, the main 
thing is to find any workable set of conventions and to stick to it. By doing this 
you will get systems off the ground faster, and you will pave the way for the 
evolutionary approach to design outlined in Chapter 2. You will also find yourself 
with systems that are virtually self-documenting and that can be easily and quickly 
changed in the future. If I had to pick out two key elements in the conventions I 
have given, I would choose (a) breaking the application down into its functional 
units and (b) avoiding ‘floating’ variables. The first of these is essential both during 
development and for the future; the value of the second only really becomes 
apparent when a long-standing system is changed. 

In these last two chapters the emphasis has been on writing APL code. I now 
want to move back to the main thread of the book, which is writing APL systems, 
although I admit that the two strands can never be wholly separated. That, after 
all, is one of the things that makes APL different. 








Chapter 6 


A new methodology 


In this chapter I want to draw some threads together. I want to show how the 
evolutionary philosophy of Chapter 2, the structure and style of Chapter 4, and the 
coding conventions of Chapter 5 can be combined into a new methodology. I 
suspect that many of my readers have come to APL and APL systems with no prior 
knowledge of computing, and that they must be wondering what all the fuss is 
about. After all, how else do you write systems in APL?! This chapter is really 
aimed at those who have spent their careers in DP departments, perhaps first as 
programmers and then as analysts: people who, like myself, find their thinking 
conditioned by years of conventional systems development. It is not easy to change 
one’s whole attitude to life, but change we must, otherwise the revolution will 
pass us by. 

As with all revolutions, this one has had the unfortunate effect of polarizing 
attitudes. With DP fighting off what it sees as an attack on its traditional patch, 
and the bureaux scrambling for lucrative new business, there is ample scope for strong 
words. The bureaux’ view is one of users retiring baffled at talk of ‘resource conflicts’ 
and ‘man years’, only to find that an APL terminal fulfils their needs in days. On the 
other hand, there must be many, many cases of inexperienced users getting into a 
frightful (and expensive) tangle with badly thought out, poorly designed systems; 
in fact making all the mistakes that the DP industry made 20 years ago! Today 
you can get a decent APL microcomputer for well under £20 000, so here is yet a 
third element to add to the already confused scene! One thing is certain - if APL is 
to fulfil its true potential as a systems-building tool, we must find a way of bringing 
these diverse elements together. 

In DP we must stop imagining that we can go on muttering ‘project evaluation’ 
or ‘unprofessional approach’, and generally behaving like a dinosaur which has just 
had its tail hacked off. The bureaux, on the other hand, should stop over-selling 
APL, without also providing the knowledge and experience to use it wisely. This 
chapter sets out to describe an approach to building APL systems which I hope will 
help anyone with an APL terminal on his desk. Whether it is to a bureau, an APL 
_ micro, or a mainframe computer, then this method should get you results in the 
sort of time you expected when you originally hired the terminal. If you work in a 
DP department, perhaps as a systems analyst, then I hope I can persuade you that 
there is a systems methodology for APL, and that maybe the APL approach is not 
so unprofessional after all - just different. 

Back to the start: you are a middle-manager with a terminal on your desk, or a 
programmer-analyst who has just had a request for help. Your ultimate aim is to 
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weld a successful team from the user and the computer, with yourself a discreet 
distance away. In fact you are trying to get from 


© to Gaa 
How should you proceed? Well, Stage 1 is easy enough, particularly if you are 
programming your own system! 


Stage 1 - Get to Know the People 


The social context of a system really does matter. Not just who is to use the system, 
but who they work for and what the local politics are. Who are the people with a 
vested interest in the success of the system? How can you work round those who 
would like to maintain the status quo? What incentives can you offer to those who 
don’t care either way? Don’t expect to get it all right straight away - you don’t 
have to. It’s easy enough to plot a course through departmental politics as long as 
you keep enough options open, and remain willing to adapt to a change in climate. 
In terms of the relationships sketched above, what you have now achieved is 


Stage 2 - Get Them Used to the Computer 


Most people’s experience of computers is limited to bits of paper that arrive through 
the post every so often - mainly bills or the occasional unwanted circular. Is it any 
wonder that they will view the entry of the machine into their own little world 
with something less than delight? It is up to the analyst to overcome this aversion, 
because overcome it he must, and soon. He needs more than just passive accept- 
ance of the system; without the active involvement of the user from the very early 
stages all his work may count for nothing. Fortunately we have in APL the ideal 
vehicle for the ‘acclimatization’ process; it is the work of but a few days to knock 
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together a little workspace of demonstration functions. Then you can invite your 
clients to a bit of ‘hands on’ computing; start from ‘2+2’, let them beat it at noughts 
and crosses a few times, and generally get across to them the impression that the 
computer is fun. A trip round the computer room is no bad idea either - all the 
flashing lights and humming disk drives are impressive in their own right, but 
equally important is the impression of people being in control. In all my experience 
of taking groups of users round our machine room the thing that seemed to fascin- 
ate people most was the operator’s console! Incidentally it’s well worth leaving a 
few games programs kicking around in the system, they may get misused occasion- 
ally but they are the best advertising gimmick ever invented! 


() 
N 


is the result of this stage. 


_ Stage 3 - Pin Down Some Data 


The hardest part of any new application is getting started; you can’t evolve a system 
from nothing. If you can dig out some elements from the mess which are liable to 
stay reasonably constant, then deal with these first. Very often this means data of 
one form or another; planning systems, for example, tend to feed on tables of 
machine-rates, or on sales estimates which arrive from elsewhere. Work done pro- 
gramming these is unlikely to need re-doing and will give the rest of the system some 
firm anchorages. It will also do wonders for your credibility, and this will be a big 
help later. 

You can also try to spot the most likely utility functions which you may want 
later. If these exist, copy them from a public library, otherwise get them written 
now. The evolution of the final system will be a much smoother process if most of 
the building material is readily to hand. 
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Stage 4 - Programming by Negotiation 


This, of course, is the crux of the matter. You, the analyst, now know a bit about 
the user’s problems, and quite a lot about the kind of programs you can build for 
him. Defining the data has done that much for you. From the other side of the 
relationship, the user has had to think in more depth than usual about what he 
wants, and is beginning to appreciate the sort of things an APL system can do. 

The relationship between user, analyst and computer is at its most tightly knit, 
and now looks like 





There is just enough of an overlap to get a constructive dialogue going, and an 
initial system will soon emerge. If you have guessed right about the utilities, and 
have set up the basic data sensibly, it should be easy enough to assemble this. In 
fact a lot of the programming can probably be done with the user sitting beside 
you at the terminal. This is where you really start reaping the benefits of that 
modular approach! 

At this point, you are going to get a lot of questions like ‘.. . do you think we 
could ...?’ or... how easy would it be to ...?’ Don’t take these at face value! 
Find out why those particular figures are wanted in that rather strange order. 
Suggest alternatives - often in a long report with sub-totals all he is actually after 
is the total lines! You know that with APL you can produce a complete cross- 
tabulation far more easily than a line-by-line report - it is up to you to say so. The 
result will be a more useful system programmed in a fraction of the time it would 
have taken had all the user’s requirements been interpreted literally. 
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I suppose the hardest part is to avoid the “You would like it like this, wouldn’t 
you?’ approach. If a user has a very clear idea of exactly what he wants, then by all 
means question him closely on ‘why?’, but be prepared to write the system basically 
as he wants it. At the opposite extreme is the user who will instinctively recognize 
the right approach when you eventually find it, but who won’t have the first idea 
how to set about describing it to you in the abstract. Here there is a very consider- 
able danger of putting words into his mouth! Be patient - keep fishing for infor- 
mation, keep putting bits of code together, keep checking how he reacts. You'll 
get there in the end, by which time you'll probably understand his job as well 
as he does! 

As with all successful collaborations, this one is based on mutual respect: you 
must respect the user’s experience and ability to do his job; you must gain his 
respect by proving your ability to get results from the computer. I used the word 
‘symbiosis’ in Chapter 2 to express the way an interactive computing system should 
spring from the fusion of the user’s know-how and the computer’s power; it is 
largely up to you to create the conditions in which this can occur. 


Stage 5 - Refining the Dialogue 


What you should have by now is a reasonably firm database, a group of fairly 
robust functions to maintain it, and a motley assortment of rather fragile code 
which feeds on it. If you are both programmer and user, then you can cheerfully 
skip this stage - what does it matter if the dialogue is a trifle illogical, and might 
collapse if you hit ‘enter’ at the wrong moment? You are, after all, always going 
to be on hand to straighten things out! If, on the other hand, you are developing 
a system for someone else to use, then you may be over the hump intellectually, 
but you still have a lot of programming to do! 

I think the hallmark of a good dialogue is probably its invisibility - like a well 
trained butler in a Victorian household it should do its job unobtrusively, but 
should always be on hand if its master needs help. This is the ideal; how the APL 
programmer sets about achieving it is another matter! For one thing, the nature 
of the dialogue will depend enormously on the type of terminal being used; when a 
system is transferred from a teletype to a VDU environment what was previously 
compact and efficient becomes terribly long-winded and slow. That said, I shall 
now try first to make some general points about dialogue design, then to mention 
one or two specific to teletype-driven systems, and finally to discuss the very 
different approach which a VDU environment permits. 

First, then, dialogues in general and some fairly sweeping statements to which 
I’m sure you can find exceptions: 


è The application must be totally robust. No conceivable combination of 
unlikely actions by the user should give an APL error message. If you have 
error-trapping, use it with care as a final long-stop, not as your standard 
catch-all. 


@ Keep the system ‘open’ (see Chapter 4) unless there is a good reason to do 
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otherwise. If, by closing part of the system, you can make it more efficient 
without in any way losing flexibility, then do so. Otherwise beware of being 
over-protective! Users are at least as intelligent and inventive as you are; as 
long as you tell them the rules then it is perfectly safe to let them loose into 
the system. As new situations arise, the user will often be able to cope with 
them without requiring a formal change in the dialogue. This removes the 
burden of designing a system which is itself adaptive. To quote from a paper 
in the 1979 UK Operational Research Conference (Tobin, 1980): 


‘If a model is highly interactive it is also highly flexible and the 
necessary adaptation can take place in the man, who can be more 
sensitive to the changing constraints and objectives. After the 
man has adapted, it will very likely be found expedient to adapt 
the model.’ 


In my view, a totally closed system is a very effective way of preventing such 
adaptation! 


@ Like it or not you are designing a language, and you must make it consistent. 
If you ask for dates in ‘DD/MM/YY’ format, then always display them like 
this. Use a consistent command (e.g. ‘STOP’, or just ‘carriage return’) to 
escape from input routines. If you have six different reports, print ‘REPORT 
1’, “REPORT 2’, etc., on the top of each. It is little things like this that 
provide the positive feedback to the user, and confirm that he does know 
where he is in the system. 


What then of teletype dialogues? The overwhelming constraint here must be the 
speed (or otherwise!) of the terminal, so every effort must be made to cut down the 
system’s verbosity: 


@ Keep wordy input prompts for ‘first-time’ users. Switch to short messages as 
soon as possible. 


@ Make it possible to stack up the answers to a series of questions when answer- 
ing the first. For example to enter data to a personnel system one might see 


NAME: Fred Bloggs 


AGE: 24 
DEPT: Op. Res. 
NAME: Joe Soap 
etc. 


or 


NAME: Fred Bloggs, 24, Op. Res. 
NAME: Joe Soap,... 
etc. 


For one way of doing this, see STACK in Chapter 8. 
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è If you use menu-selection, don’t re-display the menu every time. Users are 
perfectly capable of remembering that ‘REPORT?’ is option 5; you can always 
give them a reference card for complex parts of the system. 


@ Only print lengthy descriptive information under extreme provocation, or 
if the user specifically requests it. 


è In a complex tree of menus, it should be possible to escape from the lowest 
level right back to the top without going through all the intermediate prompts. 


Finally, what about APL systems for VDUs? Until recently APL handled the 
screen rather like an overgrown teletype, using only the bottom line for input, and 
the remainder for output. In this environment one could relax many of the above 
restrictions, e.g. menus could be displayed every time, but the fundamental struc- 
ture of the dialogue was unchanged. No more than one line of data could ever be 
entered at a time (without stacking anyway); there was certainly room only for a 
single input prompt. Now all that has changed: full-screen management is upon us, 
and suddenly we are all playing to very different rules. 

As an example of just how different the full-screen approach is, I want to quote 
some dialogue from a system which I wrote for a teletype, and have since rewritten 
for VDU. Twelve components were manufactured on a three-shift system during 
the week; the system time-tabled the production of these around an assortment 
of constraints, such as stock levels and available labour. However, it was necessary 
for the planner to be able to stop the system time-tabling certain components on 
certain days on an ad hoc basis. The dialogue went something like this: 


BAN (the name of the function) 
COMPONENT: WIDGET 

WHICH DAY, SHIFT: MON PM 

COMPONENT: SPROCKET, WED AM (notice the stack) 

etc. 


The functions to achieve all this took (excluding the STACK utility) around 40 
statements, and had to make provision for invalid component names and unrecog- 
nized DAY/SHIFT abbreviations. The end result was to update a 12 by 21 matrix, 
assigning zeros into the banned slots, and ones elsewhere. Using full-screen manage- 
ment, the entire dialogue becomes totally unnecessary! All we have to do is display 
the matrix on the screen, using ‘X’ to represent slots already banned, hold it there 
while the planner types ‘X’ in the appropriate positions, read it back, and re-assign 
into the matrix. Not only does this take the user half the time (about one-fifth of 
the CPU time incidentally) but it effectively removes any possible sources of error. 
The result is a far more elegant and comprehensible piece of program, taking eight 
statements instead of 40-odd! Obviously I want to take a more detailed look at 
full-screen management, and Chapter 9 reviews this topic in depth. 

That covers most of what I want to say on dialogue design in APL. I still believe 
that producing a good dialogue is more of an art than a science, and that the title 
of Stage 4 - ‘Programming by negotiation’ - remains a good description of the way 
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a dialogue develops. You may find bits of any dialogue irritatingly slow or imprecise, 
but if your user is happy, then let it be. On the other hand there may be parts of 
the dialogue which you find perfectly clear and concise, but which regularly confuse 
the user! These are the areas to tinker with; remember that original criterion of 
invisibility! 

Before I leave this section on dialogue I would like to throw in one or two 
mildly heretical thoughts on validation, In the traditional batch system data is keyed 
to cards or disk by a punch operator who has no way of recognizing a daft figure. 
The data is then processed, maybe overnight, and any errors get reported the day 
after. Of course if any error actually crashes one of the programs the DP depart- 
ment might be in serious trouble, with its schedules thrown out at least for that 
night. Otherwise the corrected data will go back into the system for a final run the 
day after. Because data errors can slip so easily into the system, and because of the 
damage they may cause, the writer of a big batch system must pay great attention 
to his validation routines. For people like myself who have grown up in this batch 
world, it is very difficult to adjust psychologically to the different needs of APL. 

To take the simplest case first: a program for your own use where you are always 
going to be the one who enters the figures. It’s doubtful if you even need a numeric 
check, so why not just use quad input? It probably is worth doing a length check 
on vectors though, even if only 


MAT<MAT,[C1] (1+eMAT)?+,0 


This saves the embarrassment of LENGTH ERRORS and you often want to pad to 
the right with zeros anyway. It’s also worth re-displaying the data at some point; the 
sort of errors you are likely to make (like missing a figure out) will show up clearly 
enough. 

Most APL systems fall into a category midway between this case and the batch 
approach. They are used by someone other than the author, but the user is directly 
responsible for the entry of data. This has two important consequences: the user 
will take considerable pains to get the figures right, and he will spot a mistake 
straight away. This really reduces the programmer’s task to the simple one of making 
sure that if a thumb-fingered user hits a few wrong keys then nothing actually 
stops. A simple re-display of the entered figures before filing them is always a good 
idea, but is probably only practical on a VDU-based system. 

One final point on VDU-based data-editing. The keys to worry about are things 
like ‘CLEAR’ and ‘ERASE INPUT’ which can do far stranger things to a full-screen 
editor than any combination of wrong numbers! 


Stage 6 - Digging Yourself Out 


Sooner or later there comes a point where the system must be allowed to make its 
own way in the world without constant guidance from its programmer. Even in 
systems which are entirely for your personal use, you can’t really afford to go 
crawling into the code every time something isn’t quite to your liking. In a pro- 
duction system stability is vital to the user’s confidence, and you should never 
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change anything without first making sure that all the interested parties have been 
consulted, and know exactly what is going to change, and when. 

In terms of my ‘ACU’ cartoon, we must take the final step of disengaging the 
analyst from the rest: 


<— mx.» 


Two of the best ways of achieving this stability are documentation and education. 
A properly documented system can be put away for long periods, and yet still be 
maintained at a moment’s notice, either by the author or by any other competent 
APL programmer. This removes the need for the author to remain constantly in 
touch (and hence the temptation constantly to tinker!) with the innards of the 
system. The role of user-education in achieving stability stems mainly from the 
considerable investment of time and energy the author must make whenever a 
new education program is needed. In a stable system ‘local experts’ soon develop 
among the regular users, and the job of training people new to the application will 
quickly be taken off the analyst’s hands. 


To summarize the progression through Stages 1-6: 


SR. 


oe S- 
SO O 


. which makes it all look deceptively straightforward! In practice of course, 
different bits of the system will be at different stages, and you may often find 
yourself backtracking to attack areas which somehow got left out first time through. 
As for documentation, that obviously merits a chapter to itself, so I think that just 
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about wraps up this ramble through the APL methodology. Yes, it is different, it is 
unstructured, it is unpredictable, but it gets the job done and that, in the end, is 
what counts. 





Chapter 7 


Documenting an APL system 


There are two types of APL system, two types of documentation, and two places 
where it may be kept: 


@ Personal systems are systems put together entirely for the author’s own use; 


@ Production systems are systems written for others to use, and on which some 
significant part of a company’s operation depends. 


è System documentation explains how the system works; 

@ User documentation explains how the system is to be used. 

@ Internal documentation is held in the workspace(s) that make up the system; 
@ External documentation is held on paper in a manual/project file, etc. 


When documenting an APL sytem, you must first decide which type it is: per- 
sonal or production. (If the former, is it certain to remain so?) Then apply the 
criteria below to be sure that your level of documentation is at least adequate. 


Personal systems 








Internal External 
Reasonably modular ? function listings ? 
System Sufficiently commented Relationships between 


Follows a naming convention variables 


Brief “DESCRIBE” as OLX Included on a list of all 

Helpful prompts your systems with a 
brief note of what it 
does 


User 





Virtually all the documentation is internal, making it: 


@ easily updated 
@ readily available 
- @ inseparable from the system 


Thus you have no excuse for omitting to change the documentation as (or before) 
you change the code. You will always be able to refer to it when you most need 
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to, and you won’t risk losing the one scrap of paper which just happened to have 
these vital notes on it! 

For personal systems, the prime purpose of the system documentation must be to 
make change as easy as possible. Comments need be little more than brief notes to 
yourself, but they should still be there. Things which are obvious when a function is 
written may be anything but in two years’ time; for one thing your style may have 
changed markedly by then. The value of modular code, and of strict adherence to a 
naming convention, I hope I made clear in Chapter 5. You may not need any exter- 
nal system documentation at all, but if you have access to some suitable utilities, 
then a set of function listings won’t come amiss. The other thing I often find rather 
handy is a rough diagram showing the relationships between the various APL vari- 
ables in the workspace. I think I can best explain what I mean with an example: 
suppose we have a little APL system to keep a log of our company’s foreign 
exchange commitments. This will have variables such as 


AAMOUNT vector of outstanding quantitites 


ADATE date each is due 

ADESCR matrix of descriptions of each 

ACCY index into currency table 

ACREF matrix of currency names 

ARATES exchange rates (spot and forward) for each currency 


I would draw these as follows: 


ADESCR 


+H Zcozrp 
MiH4bpO0p 
<~<OOp 





Num. Num. Ptr. ACREF ARATES 
8 — 5 
Char. Num. 


clearly depicting the relationships among the various data entities. This sort of 
chart makes clear where the potential traps lie. For example: 


@ To delete an entry from the log we must apply the same mask to AAMOUNT, 
ADATE, ADESCR, and ACCY, but not to ACREF or ARATES. 


@ To delete a currency from the system, we must delete any log entries for that 
currency and we must also adjust the remaining elements of ACCY, which 
would otherwise point to the wrong place. 


The use of such data structures will crop up again in Chapter 12, in the section on 
efficient use of storage. 
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The internal user documentation is again no more than a few reminders; a very 
abbreviated DESCRIBE won’t take long to type in, and will save the occasional 
browse through )FNS when you forget what your top-level functions are called. 
I doubt if you need any external user documentation at all. Perhaps just a note 
of the workspace name and a one-line abstract of what it does. 


Production systems 





Internal External 

Highly modular 

All functions re-creatable 
from the comments alone 


Function listings 
Function cross-reference 
Function tree-structure 


System Strict use of naming Variable-function 
conventions cross-reference 
Very straightforward code Chart of variable 
relationships 
Screen-panel listings 
Workspace summary 
Function specifications 
Summary of file access 
‘DESCRIBE’ pointing to Some notes on the 
more detailed ‘HOWX XX’ hardware, e.g. siting of 
functions VDUs, keyboard train- 
Long/short prompts ing, log-on, etc. 
User (teletype) What to do when some- 
HELP frames (full-screen) thing goes wrong 
‘AUTHOR’ giving name System user-guide: 
and phone number of notes on all the com- 
contact 


‘RELEASE’ giving current 


mands; the general 
style of dialogue, and 


release number and date specific prompts 
which might cause 
trouble 

A clear description of 
the library commands, 
i.e. LOAD, etc. 

A clear statement of any 
known limitations, 
e.g. quantity of data 





Before I go on to take each of the four areas in more detail, I want to tackle the 
general point of how big an application can be before it should be split over several 
workspaces. The penalty of splitting a system up in this way is the introduction of 


an additional level of external documentation over and above that needed for each 
workspace. For example 
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MAINT 






REPORT 


where workspace ‘MAINT’ contains the functions to read and update data on 
machine speeds, etc. (held on FILE1); ‘SCHED’ uses this data to produce a produc- 
tion time-table, which it stores on FILE2; ‘REPORT’ uses the data on machine 
speeds again to print the stored schedule. 

Such system flowcharts can get surprisingly complicated alarmingly quickly, and 
you will also need some sort of summary of contents and access for all the files. 
However, splitting an application up in this way does keep the contents of each 
workspace within reasonable limits. Again it’s a personal view, but I feel that an 
application should be split up when it totals around 2000 lines of APL (i.e. 80-100 
functions), and that once split each section should be kept below about 1000 lines 
from then on. An advantage of this fragmentation is, slightly paradoxically, a more 
‘user-friendly’ system. Most users are much happier with three or four workspaces 
each with, say seven commands, than with one workspace having over 20 
commands. 

Enough, anyway, of this digression. What about the documentation needed for 
each workspace, and, from the user’s point of view, for the system as a whole? 
Stick rigorously to the coding conventions of Chapter 5 (i.e. follow a strict naming 
convention, write the comments first, avoid floating variables like the plague, keep 
functions short) and you can’t go far wrong. There are only two further suggestions 
I would make: have a function (or variable) ‘HOWGLOBALS’ which describes in 
detail the contents, nature, and purpose of all your global variables; secondly, if 
you do any file access, then a similar function ‘HOWFILES’ should list all the files 
read/written/updated, with details of the variables fetched from/dumped to each 
file. 

What then of the external system documentation (otherwise known as paper- 
work, bumf, etc.)? - the completion of which always seems to form Stage 5 of the 
well-trained analyst’s progress to fame and fortune! 

Let’s start with a nice fat folder, with the workspace name clearly written on the 
spine, and decide what ought to go into it. Obviously a complete set of function 
listings, a cross-reference of function calls, and a cross-reference of global-function 
references. All this can easily be produced automatically (see Chapter 10) as cana 
pictorial representation of any full-screen panels, and a separate listing of any ‘HOW’ 
or ‘DESCRIBE’ functions. So far, so good, and the additional paperwork needed is 
pretty minimal. I would suggest using forms along the lines of Figures 7.1-7.3: the 
first as a checklist; the second as a paper back-up for the ‘DESCRIBE’ and ‘HOW- 
FILES’ functions; the third to fill any gaps left by your program comments. In 
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Workspace Name _._ 


System Flowchart 





N 


Workspace Specification 


WN 


File Layouts 


Function Specifications 


5 | Global Variable Descriptions 


WS Structure Analysis (Tree Diagram) 







7 | Function Listings 


Function Cross -reference 


Global Variable Cross-reference 





Document Utility 






VDU Layouts 


Printer Layouts 


Figure 7.1 APL workspace run book contents 


particular this ‘function specification’ makes specific provision for those quasi- 
globals which can cause so much trouble, and it gives space for a reasonably full 
description of the arguments and results. In my experience these are the quanti- 
ties most likely to be of interest to the future APL programmers who must amend 
(or debug) your system. Whether you need a typed ‘global variable’ description 
depends on whether or not you already have ‘HOWGLOBALS’ in the workspace, 
which leaves only item 11 on Figure 7.1 - the printer layouts. These I find some- 
thing of a bugbear, because I normally draft them rather roughly and then mess 
around with the code until the report looks right. I think the best compromise 
is probably an annotated sample of output, with notes on the field widths, starting 
columns, etc., where these are likely to be relevant in the future. 

For the great majority of APL systems this really is all you need - after years 
spent ‘completing the documentation’ of conventional systems the APL philosophy 
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System 










Workspace Name 


Description 


| Purpose /Comments | 


Figure 7.2 APL workspace specification 





comes as a blessed relief to the over-worked analyst or programmer! Why is there 
so much less paperwork? Well, one obvious reason is the way APL cuts down the 
lines of communication which separate the user from the system. Every link in the 
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System 





Function 





Argument (s) 






Returning 


[Common vars Set Up 


Common Vars Referenced Localized in Function 


Figure 7.3 APL function specification 








chain meant a form to fill in, and even a simple program amendment could generate 
an absurd amount of waste paper. 
Finally, on the subject of paper documentation, I want to offer a few thoughts 
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on the rather vexed question of ‘documenting the algorithm’. What on Earth do 
we do when a brilliant young OR man, after months of apparently unproductive 
head-scratching, suddenly invents an inspired way of solving some planning prob- 
lem? Uttering strange cries he makes a bee-line for the nearest APL terminal, 
there to remain until his brainchild has taken shape. Even as he adds the finishing 
touches he places his manager firmly on the horns of a particularly unpleasant 
dilemma! Such solutions are the work of one man alone; how can the department 
possibly offer credible back-up and maintenance when that man leaves? My view 
is that APL was conceived for just this purpose! We shouldn’t lose sight of the fact 
that it is first and foremost a means of expressing complex algorithms clearly and 
concisely, not a means of programming computers. If, by providing them with an 
APL interpreter, the OR department forces its bright boys to write their algorithms 
in a consistent and powerful notation, then I would argue that it has taken a big 
step along the road to maintainability. With an APL system, paper documentation 
of algorithms is essentially unnecessary! 

Back to firmer ground with the next item on the list - internal user documen- 
tation. Again let me start with a plea for open systems. In a closed system every 
choice means a menu, and every menu needs a ‘HELP’ function. In particular it is 
all too easy to get a user lost somewhere near the top of a tree, when he really 
wanted to be on a different branch altogether. The best user documentation in the 
world won’t get him out of this one! In an open system the user is never more than 
one command away from APL, and thus never more than two commands away 
from ‘DESCRIBE’. Because there are no complex trees to get lost in, the total 
amount of ‘HELP’ in the workspace is minimal, and can be kept to specifics, such 
as the correct format for dates, or the known abbreviations for the machines in a 
production scheduling system. Two other functions which I might leave lying 
around are ‘AUTHOR’ and ‘RELEASE’. The former simply gives the users a phone 
number to ring in case of trouble; the latter returns a release number (and date) and 
would normally be included in the Latent Execution. This is particularly useful 
where many copies of a workspace are in existence, and you do not necessarily 
know that all your users have furnished themselves with the most recent one. If 
someone rings up with a problem it is very convenient to be able to ask them to 
type ‘RELEASE’, so that you know straight away which version of the program 
you are dealing with. 

So far all this documention requires some specific action on the user’s part to get 
at it. Equally important is the documentation he gets willy-nilly as part of the 
dialogue. At this point there is again a marked divergence between teletype and 
VDU systems; the former being much the simpler of the two to deal with, but the 
latter far more satisfactory when you get it right. As always, what the teletype 
system must fight is the speed of the terminal. How to provide enough information 
for the novice user, and yet not slow the system down so that it infuriates the 
expert? There are two basic ways of attacking the problem: the use of alternative 
long/short prompts; and the provision of stacking, so that the expert can bypass 
most of the prompts altogether. Which method you use (of course there’s no reason 
why you shouldn’t use both!) is largely a matter of personal preference. Another 
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way out, and one which I have used perfectly successfully, is to stick to brief 
prompts throughout and to compile a comprehensive user-guide which gives the 
more detailed explanations. 

The problems in producing a ‘friendly’ VDU system are very different. In an 
environment where a complete ‘HELP’ frame can be flashed up in a couple of 
seconds the big danger is not one of slowing the system down, but of swamping 
the inexperienced user with information. Keep screen panels reasonably simple, 
and avoid highlighted or reverse-video fields unless you want a very strong emphasis. 
Rather than putting everything on the same screen, split things over three or four 
screens, and use PF keys to switch between them. Keep the bottom couple of lines 
free for notes on what the PF keys do, and reserve one PF key (always the same 
one, obviously) to switch to a ‘HELP’ frame. Don’t use wordy error messages for 
simple things like non-numeric data - it is quite adequate to bleep the screen, high- 
light the offending field, and plonk the cursor back under the offending character. 
Keep to a consistent set of PF keys for things like ‘previous page’, ‘next page’, and 
‘quit’. Set the screen up to make the best use of any hardware tab keys, e.g. if there 
is a ‘tab to top left’ key then use this field consistently for your command area. 

I’m not sure how much of this really qualifies as ‘user documentation’. In many 
ways a well thought out full-screen system, particularly one which involves a fairly 
complex editor, is so much more straightforward than the teletype equivalent that 
most of the traditional ‘HELP’ material can be quietly forgotten about. 

So to the external user documentation, and this chapter finally enters the home 
straight. The section itself divides into three topics: using the hardware; using the 
system; and what to do when something goes wrong. 

First, the hardware, and very important it is too. It’s all too easy to tell a user 
‘.. . just type )LOAD FRED and you'll be away ...’ without realizing that most 
APL keyboards have at least two sets of ‘)’, some ‘]’ and possibly even the odd ‘}’ 
to add to the confusion. The first thing to appreciate is that a user may not even be 
familiar with an ordinary typewriter, let alone the considerable sophistication of a 
VDU keyboard. If you can arrange a formal keyboard training session through, 
for example, the data preparation department, then do so. A couple of hours under 
the wing of an experienced teacher will be enough to give anyone a reasonable feel 
for the hardware, and one barrier between the user and the system will have been 
broken down. Incidentally, many APL programmers would probably benefit from 
a decent keyboard training too! When you are faced with typing in a lengthy 
‘DESCRIBE’ function, then being able to touch-type will both speed the job and 
cut down the eye-strain. Referring constantly from your notes to your fingers to 
the screen and back again can be very tiring, and is certainly not good for you! 
Anyway, that is by the by; the main topic is ‘the user and the hardware’, and there 
are a couple more small points I would like to make. 


e Siting of VDUs. Beware of reflections, particularly from fluorescent lights; if 
these are aligned parallel to the screen they can cause a particularly irritating 
flicker. Make sure that everyone knows how to adjust the brightness, contrast 
and bleeper volume. 
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© Log-on/log-off procedure, Over a dial-up line this is often the hardest part of 
the whole dialogue. Have a clear crib pinned up near the terminal, but make 
sure that the password doesn’t get pencilled in by someone! 


@ What to expect when the system goes down, and who should be rung up to 
find out how long the problem is likely to persist. 


Finally on this subject, a short true story. Once upon a time a company’s VDUs 
displayed a rather pretty version of the company logo, together with a polite invi- 
tation to log on. One day it became necessary to change to a new operating system, 
and for a short while all the screens said ‘THIS TERMINAL IS LOGGED ON TO 
THE NETWORK SOLICITOR’. On seeing this one occasional user assumed, in all 
innocence, that the company solicitor had commandeered the entire system! Only 
after several days’ patience did he ring up to find out why!! Moral: just because you 
have learned to tolerate the meaningless jargon that comes free with the operating 
system, it doesn’t mean that your users have! 

Having made sure that all concerned are happy with the keyboard, and know 
how to log on to the computer, then the next stage is to make them familiar with 
your system. Perhaps the hardest thing about the system user-guide is finding out 
if it’s actually doing good! So often you lavish several weeks’ care and attention 
on a beautifully produced document, hand it over to the users, and never hear any 
more about it. Again I feel that the best place for the documentation is in the 
workspace, and that the only things needed in the user-guide are the following: 


e A brief explanation of the purpose of the system, and a clear statement of 
any known limitations. For example in a system to handle critical path net- 
works the user-guide should obviously state the maximum number of activi- 
ties allowed. 


è A clear description of the APL library-management commands where these 
are relevant to the application. 


© A general introduction to the type of dialogue used; for example how to 
stack commands, how to escape from input loops, and how to ask for help. 


@ A glossary of the main user-commands, with an example of the use of each. 
In the case of VDU systems, annotated diagrams of all the screen panels, with 
some kind of ‘map’ showing the way related screens link together. A possible 
notation for such maps is discussed towards the end of Chapter 9. 


e@ Samples of all the reports which the system can generate. 


You can go into great detail on the prompts and expected responses for each, but it 
is probably not necessary given a reasonably friendly dialogue. 

Finally then, what to do when things go wrong and you don’t have a system 
which can trap the error. There is an interesting question here as to whether you 
should lock the main user-functions. If you do, then ‘DOMAIN ERROR... . UP- 
DATE’ isn’t a vast amount of help in finding out what went wrong. On the other 
hand, with unlocked functions you are risking the possibility that a user may ignore 
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the ‘LENGTH ERROR . . .’ and may restart UPDATE. If it is wrong first time, it 
will certainly be wrong second time, and it may be progressively corrupting pre- 
cious data. If the workspace is then saved, with two or three crashed functions on 
the stack, you may have a pretty tricky recovery job ahead of you! 

I think the best plan is probably to leave things unlocked, but to lay down a firm 
warning that persistence in the face of an APL error-message (particularly one like 
WS FULL) is dangerous. The best plan is probably to save the crashed workspace as 
it stands with a name such as ‘ZAP’; to log off; and to ring for help. It’s a procedure 
the user should never need, but one that you should make sure he knows. 

At that point, I think the time has come to call a halt. Documenting in APL may 
not be quite as good for the soul as documenting a conventional system, but it is 
still a bit of an uphill struggle. Now for a bit of blessed relief (for the author as well 
as the reader!) as we move back to APL itself. 











Chapter 8 


Useful functions and common idioms 


After much thought, I have come to the view that there is no sensible way to 
arrange this chapter. Related idioms are often used in totally unrelated applications, 
and similar applications require an incredible diversity of idiom. Thus, rather than 
attempting to group the material either by idiom, or by application, I am simply 
going to plough through the APL primitive functions in the conventional ‘reference 
card’ order, giving a selection of the idioms relevant to each. 

Idioms containing more than one function will normally be included only 
against the first occurrence, but may occasionally get a cross-reference from the 
others. Operators (e.g. Scan) are not treated separately, i.e. ‘<V will be found under 
‘<’, not under ‘\’. Having done this, I shall then collect together some idioms which 
are particularly relevant to the subject of text processing. Although many of the 
examples are given as small functions, there is obviously no reason why they should 
not be included directly in your code, rather than called as utilities. 

Incidentally, this chapter was put together on an APL terminal using a slightly 
doctored version of the full-screen editor which is described in Chapter 10. Any 
code has either been included from tried and tested functions, or (in the case of odd 
lines of APL) it has been tried out during compilation from within the editor. This 
should guarantee an absolute freedom from typos in the places where it matters 
most. If you do find any mistakes, I should be glad to know of them! 


+ (Conjugate) 
When experimenting with bits of code at the terminal, how about 


+VAR¢expression 
as a rather easier way to display the result than 


O+VAR¢expression 


+ (Plus) 
Four idioms are of interest here: 
@ Plus with a Boolean result, to avoid a branch: 


SCORE¢SCORE+ANSWER=RIGHT 
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e Counting matches in two vectors of equal length: 
DOUBLES+¢( ?36p6)+.=?3696 

@ Projection of stock levels, given opening stock, production, and sales: 
STOCK+OSTK+ ( + \ PRODUCTION) -+\SALES 

@ Sort a list of words by length of word: 


LIST¢LISTCYLIST+.#' '3] 


— (Subtract) 


Often successive elements of a vector might be start and finish times of a production 
run; to subtract these (i.e. VEC[11] — VEC[10] ), thus evaluating the run time: 


RUNTIME¢-/VEC([11 10] 


X (Signum) 
Only one idiom here: 


@ Range check; to return” 21 0 1 2 for conditions ‘below lower limit’, ‘on 
lower limit’, etc.: 


RESULT¢+/xARGo ,-LIMITS«¢LOWER , UPPER 


X (Multiply) 
Again, this has interesting effects when used with a Boolean result: 


Bool X VALUE gives VALUE for Bool= one 
ZERO for Bool = zero 


è To add £5 to all overdue bills: 


BILL¢BILL+5xDATE>DUEDATE 


To get the position of the right-most ones in a Boolean matrix: 


M 
0100 
0110 

MP .x.11+0M 
2 3 


Another very common requirement is to multiply a matrix by a vector, either 
by row: 
RESULT+MATx ( pMAT ) pVEC 
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or by column: 


RESULT¢MATx& ($pMAT ) pVEC 


+ (Reciprocal/Divide) 


Again, only a couple of expressions, which are probably better classed as pro- 
gramming tricks than idioms proper: 


@ Sum of parallel resistors: 
RES¢#+/#R¢R1 ,R2,R3...... cece etc 
@ Expressions of the form 


Avg iC 
BD” 


can be coded as 


+/A,B,C,D... 


* (Raise to Power) 
Yet again, this one comes in handy with Booleans: 


VALUE * Bool gives VALUE for Bool= one 
ONE for Bool = zero 


@ To charge 6% interest on all bills over 6 weeks old: 
BILL¢BILLx1 .06*AGE>6 


@ To select the major diagonal of any array: 


DIAGONAL+<¢ (1 * pARRAY ) SARRAY 


[ (Maximum) 
è Locate the largest element of a vector: 


POS¢VEC1fT /VEC 


@ Catenate a vector as the bottom row of a matrix, padding either as needed: 
M+(((0,LEN)[eM)4+M),(€1] LEN+V 
L (Minimum) 


© To cover ‘Bare Input’ and cope with the user backspacing into the prompt by 
accident: 
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Z¢+BAREIN STRNG;A 


[1] aUNVALIDATED INPUT ROUTINE FOR CHAR. DATA. 


C2] M+A+,STRNG 
C3] Ze((+/A\' '=Z2)LpA)+2¢,0 
y 


L (Floor) 


@ Sometimes used (along with residue) as a sort of ‘poor man’s decode’; i.e. if 
2005 is really ‘2 men, 5 days’ then 


MEN¢L0.001xMENDAYS 


@ Also to demote an integer variable (which has somehow become real) to 4 
bytes: 


VARtL VAR 


| (Magnitude, or Absolute Value) 
e Rather useful for splitting up fields on the screen, e.g. 
__2.005]__3.000| 


but apart from that, I am rather scratching my head on this one! 


| (Residue) 
This comes in very handy when you need to force an incremental process to cycle. 
© To dump data on to a set of 20 work files: 
DUMPATO FILENO+1+20|FILENO 
@ To throw a new page every 60 lines: 
e (0=60|LINECT+LINECT+1)/'ANEWPAGE PCT+PCT+1' 
@ Also there is the other half of the ‘Decode’ equivalent: 
DAYS+1000|MENDAYS 


@ Finally a distinctly silly way of generating prime numbers (and getting WS 
FULL if you’re not careful): 


PRIMES¢(2=+/0=(i1N)°.]iN)/1N 


® (Base X Log of Y) 


When sorting character data, a common technique is to use | to clump columns 
together. Because the numeric precision of the computer is finite (2*31 is the 
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largest number that can be stored without getting blurred), the number of columns 
per clump depends on the collating sequence (ACS). 


è For an alphabetic sort (39 characters): 


+MAXCOLS€L (pACS)02*%31 
5 (10 for 2*56 which some systems allow) 
! (Binomial) 


Well, if you’re feeling particularly peeved with the world and want to write some 
really obscure code, how about 


Boolean! VALUE gives ONE for Bool = 0 
VALUE for Bool= 1 


Apart from that, I don’t really think that this rather specialized mathematical 
function lends itself to idiomatic use! 


< (Less Than) 
è Are any values below minimum limit? 
WARN¢STOCKV . <MINSTOCK 
e Useful effect on Boolean vectors of leaving only the left-most ‘T’ switched on: 
<\0 010111 


0010000 
For example, to remove duplicate rows in a table 


MAT+(1 1 &<\MATA.=QMAT)/MAT 
or (but marginally less efficient) 
MAT<¢(V/<\MATA .=QMAT) MAT 


This is one case where a looping approach can be a great deal faster. For tables with 
large numbers of duplicated rows, the ‘all-play-all’ method of ‘a.=’ does an awful lot 
of redundant comparisons. See Chapter 11 for the exact figures. 


< (Less Than or Equal to) 
è If you use this on Booleans, it will leave only the left-most zero turned off: 
<\1 1001 0 
11011 1 


è Here is a little function (ALKP) to find the minimum input needed to identify 
a command unambiguously: 


[1] 


[2] 
C3] 
C4) 
C5] 


CL¢',' ATAB 'ADD,UPDATE ,FETCH ,FILE! 


CL ALKP 'U' 
CL ALKP 'FE! 


CL ALKP 'FILL! 
i.e. not found 


CL ALKP 'F! 
also not found, being ambiguous 


POS¢TABLE ALKP CMD;M 


AFIND UNAMBIGUOUS REFERENCES TO CMD IN TABLE. 


M+( (pTABLE)p(1+oTABLE)+CMD)=TABLE 
M+(p,CMD)<+/A\M 

>(Of 1++/M)+0,POS<+1+ eM 

POS+«M11 
y 


è To create an upper triangular matrix: 


MAT¢(iN)°.S1N 


> (Greater Than or Equal to) 


The ‘°.>’ construction has obvious application in drawing histograms, e.g. 


HIST¢! O'(1+VECo .21f /VEC) 


but these histograms can do rather more than meets the eye. 


è The well known vector-to-matrix conversion 


',/' ATAB 'FRED,JOE/HARRY, ,X'! 


FRED 


JOE 


HARRY 


X 


can be achieved with 


C1] 
C2] 


C3] 
C4) 
C5] 
C6] 
C7] 
C8] 


MAT<DELIM ATAB VEC;POS 


aTURNS A VECTOR INTO A TABLE, 
ABREAKING IT AT GIVEN DELIMITERS 


VEC¢VEC ,14*DELIM 
VEC+«(~POS¢VEC eDELIM) /VEC 
POS+POS/1pPOS 
POS+POS-1+0, 1+POS 
POS¢POSe .21f /0,POS 
MAT<(pPOS)p(,POS) \VEC 
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@ Or to mimic compression on a matrix, 


1 ACOMP ABCDE 
0 FGHIJ 


where the rows are padded with zeros or blanks as appropriate: 


R¢MASK ACOMP MAT;LEN 


[1] aMIMIC COMPRESSION ON RANK 2 ARRAYS : PADS R 
[2] aWITH ZEROS OR BLANKS AS REQUIRED. 


[3] LEN+¢l/+/MASK 
[4] R+(,(+/MASK)°.21LEN)\(,MASK)/,MAT 


[5] R+((1+pMAT),LEN)pR 
y 


In both these examples, a histogram is created, then ravelled, to generate the 
correct number of blanks (zeros) for the subsequent expansion. 


= (Equals) 


All the inner products (a= etc.) are probably better left until they crop up under 
the left-hand function of the pair. That leaves 


@ Is OBJ all Boolean valued? 


A / „OBJ =0BJ=1 


è If so,demote it to its most compact form: 


OBJ+0BJ=1 


Also of course, the outer product ‘°.=°. This certainly has no shortage of uses, but 
first a word of warning. Many quite respectable constructions use 


1 1 2Ac.?B 


to generate a large (but redundant) matrix, then select the plane which actually 
means something. This may look neat, but it does involve the CPU in a lot of 
unnecessary labour, and is rarely an efficient (as opposed to elegant!) solution. 

That said, if you really do want to get a matrix, then the outer product is a 
very good way of doing it. 
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è To construct an identity matrix of side N: 
IDENT¢(iN)e.=1N 
e To construct expressions, e.g. 
Total OF sales BY area 
where SALES and AREA are vectors, one uses ‘°.=’ as ‘by’ and ‘+. as ‘of’: 


TOTAL¢SALES+ .xAREAc .=1f /AREA 


Or if AREA is a set of pointers into a table: 


| sSIttilv | A | | NORTH | 
[Al JA I | R | ---|------- >| SOUTH | 
oe oe ee ee | | E | | | EAST | 
| BE] | ul [A] -->] | WEST | 
is | | E | pee 
then 


TOTAL*SALES+. xAREA°e ,=114pAAREAREF 


# (Not Equal to) 


Again, leaving aside things like ‘v. there is one fascinating use of this function, the 
detailed workings of which never fail to amaze me! 


#\Boolean 


has the quite remarkable property of generating a result which flags the parity of 
the Boolean. 


@ To remove the bracketed text from a vector: 


STR¢'REMARK(IN BRACKETS) ,(MORE) ANOTHER REMARK! 
M¢STRe'()! 
(~Mv#\M) /STRING 


REMARK, ANOTHER REMARK 


This sort of thing comes in very handy in workspace documentation because, 
when compiling a function cross-reference, you naturally want to ignore any 
occurrences of a name within quotation marks. A quick ‘¢\’ works wonders in 
chopping out all the unwanted bits before the function is searched. Anyway, more 
on that theme in Chapter 10. 


@ Another common use of ‘#’ is to underline headings: 


H+'CODE DATA DESCRIPTION! 
H,CO.5] (H! 1)\t ! 


—— ome e ro = aame oe ee eS ED Ses SD ES Oe eae GD eS 
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@ Finally, to check if a Boolean is all ones, or all zeros: 


CHECK¢#/1 Oe€BOOL 


A (And) 


Something of an embarrassment of riches on this one! To include all the material 
under ‘A’ would rather overload this section, so I’m going to resort to separate 
sections for ‘a.=’, ‘Af and ‘AVY to make life easier. 


A= (Table Match) 


This has virtually become a compound function in its own right; in fact most APL 
interpreters treat it as such. Consequently, it tends to execute far faster than you 
would expect if it really made all those matches before doing the ‘n’ half! Of course 
it cheats, and stops as soon as it comes on a mismatch. 


@ The obvious use is in table lookup: 


TABLE 
FRED 
JOE 
HARRY 


(TABLEA.=54'JOE!') 11 
2 


@ Or simply to check for a given string: 
+('END'A,=3+INPUT)+EXIT 

@ Or to remove any completely blank rows from a table: 
TAB+(~TABA.=' ')/TAB | 


@ And so on. 


Ni (Are all...) 


This reads ‘Are all . . . conditional expression’, and again it cheats. You can easily 
test this by timing: 


Bea/A for a+¢10000+1 (<1 ms) 
and A+10000o91 (16 ms) 


The first expression drops out as soon as it hits a zero, and is again anomalously 
fast. 


@ A common use is in validation: 


+(A/,TABLEe' 0123456789. ')+ERROR 
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@ An interesting sideline is to test whether a vector forms a permutation: 


TEST+A/VEC=AAVEC 


A\ (While true) 


This has the very useful property of switching off all the ‘ones’ which occur to the 
right of the first zero: 


\11100110 
114100000 

© To left-justify a word list: 
LIST+¢(+/A\LIST=' ')$LIST 


@ Ina text editor, you might find a command 


CMD¢INSERT/RA COMMENT 


to insert the comment line after the current line of the function being edited. 
To get rid of the unwanted command (which could have been abbreviated to 
‘T, ‘IN’, etc.): 

14(~A\CMDet INSERT! ) /CMD 


AA COMMENT 


V (or) 


Not surprisingly ‘v\’ has very much the opposite effect to ‘a\’: it turns on any 
zeros to the right of (or below) the first one: 


v\0010010 
0011111 


@ To strip leading blanks from a string: 
STRING+(v\STRING#' ')/STRING 
@ To mimic dyadic iota on compatible tables: 


POS¢B AIOTA A 


[1] aRATHER SIMILAR TO <<BiA>> WHERE B AND A ARE 
[2] aTABLES OF THE SAME WIDTH. IT RETURNS ZERO INSTEAD 
C3] AOF <<1+1+pB>> IF NO MATCH IS FOUND. 


C4] POS¢+/V\O<\BA.=8A 
y 


... Often it is more use to get zero for ‘not found’. 
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To illustrate to use of AIOTA: 


CAT CAT 
HAT AIOTA HAT 
HAT HAT 
MAT FAT 
MAT 
iS 
12204 


If you genuinely want the real thing (i.e. 1 2 2 5 4), 
POS¢(<\(AA.=8B) ,1)f .x114+1490B 


will achieve the desired result. 


~ (Not) 
@ Another way of demoting a Boolean object to its most compact form: 


BOOL¢~~BOOL 


A (Not and, or Nand) 
@ Removal of leading/multiple blanks from a string: 
STR&( 1+(M,1)*1,M¢STR=! ')/STR 
@ ‘AV to bypass a branch where one of two alternatives must be selected: 
(#\ 2p TEST) # TRUE ',C0.5]'FALSE! 


This relies on 


a\1 1 is 10 
*\0 O whichis 0 1 
X (Nor) 


So far, idioms based on peculiar properties of this function have, alas, escaped my net. 


? (Deal) 
@ To shuffle a vector: 


VEC¢VEC[ (pVEC ) ?pVEC] 


p (Shape of...) 
è Finding the RANK of any APL variable: 
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RANK+¢p pVAR 
@ General form for any process which will operate only on vectors: 


RESULT¢(pMAT)p ....process.... ,MAT 
e.g. character mappings, such as a translation to upper case for non-APL 


terminals: 


UP+AUPPER LOW;S1;S2;SWOP;SHAPE;NEW 


C1] aAUPPER CASE TRANSLATE. 

C2] S1¢'abcdefghijklmnopqrstuvwxyz-'! 
C3] S2¢'ABCDEFGHIJKLMNOPQRSTUVWXYZ ! 
C4) SHAPE+¢pUP¢LOW 

[5]  +(+/SWOP+(LOW+,LOW)€S1)+0 

C6) NEW+¢SWOP\S2[(S11SWOP/LOW] 

[7] NEW[ (~SWOP ) /1 PNEW]e(~SWOP)/LOW 
C8] UP+SHAPE pNEW 


In a similar vein is the expression to replace a selection of characters in a 
matrix with blanks: 


TEST 
| | 145.6|___ [34 
S E. 
2 | 5.667 | 56 
(pTEST)oM\(M+,~TESTe!'|_ ')/,TEST 


45.6 34 


@ Two slightly frowned-upon ways of saving a line of code: 


+LAB,pMAT¢..... expression 
ERR: 7*INPUT,pO«+'INVALID DATA ... PLEASE RETYPE! 


The second of these is probably fair enough, because (a) it probably never 
gets executed! (b) it doesn’t detract from readability. 


@ Another idiom which has practically become a language element: 


LEVEC or 114pMAT 


Examples of this one can wait for iota, but it is again worth noting that 
many interpreters cheat, and will do ‘11 tpMAT’ as a single operation without 
ever going near MAT at all. 


@ To pick up the last row of a matrix: 
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VEC¢MAT[ ( pMAT)[1];] 
@ Or to pick up the last column of a matrix: 
VEC¢MAT( ; (pMAT)[2]] 
as a vector; 
VEC+MAT[ ;1+pMAT] 
as a one-column matrix. 


A common construction in dialogue is to use null input (i.e. a straight carriage 
return) to close a cyclic process. This leads to code like 


AGAIN: +(pCMD¢BAREIN 'ENTER COMMAND :- ')+DONE 
+AGAIN 


for teletype dialogues. 


p (Reshape) 
Along with the monadic ‘shape’, rho frequently crops up in the general construction: 
OBJECT+( ..expression.. pOBJECT) pOBJECT 


è To turn either a scalar or a vector into a one-row matrix (leaving rank 2 
objects as they are): 


MAT¢(~ 241 1,pOBJECT) pOBJECT 
è To tum a vector into a one-column matrix: 
VERT+¢((pVEC) ,1) pVEC 
or 
VERT+ (1 , VEC ) pVEC 
Or 
VERT+& (1, VEC) pVEC 


In spite of the double brackets, the first of these is actually the most efficient 
(marginally) of the three. All are infinitely preferable to 


VERT¢VECe .+,0 

. . . and anyone caught writing 

VERT+VEC°,x,1 Or VERT+0 1+VEC,[1.5JVEC 
deserves a summary execution. 


Finally, a couple of handy tricks: 
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@ 'tpOBJECT selects the first element of OBJECT asaSCALAR 


@ 0=1+0p0BJECT returns 1 for numeric objects, and O for character. 


ı (Index Generator) 
This forms part of many of the most commonly encountered phrases in APL. 
© Conditional branch: 
+LABx1A>B 
See Chapter 4 for the reasons why I don’t particularly like this one. 


@ Find the elements of VEC which fulfil a given condition: 
POS¢( ..expression.. VEC)/1pVEC 
VEC[ (~VECe'0123456789.!')/ipVEC]<e! 1 

@ Convert a vector of positive integers into a mask: 


(1 f /VEC ) VEC 


ı (Index of...) 


Again, a fair shoal of useful idioms, many relying on the fact that dyadic iota 
effectively reverses [.. .], i.e. 


OAVCOAV:iCHARS] is CHARS 


Because it returns 1 + pVEC, iota can be used to provide default values for unrecog- 
nizable input: for example if an abbreviation for a shift may be keyed as ‘M’, ‘A’, or 
ʻE’, then to assume ‘M’ as the default 


SHIFT¢'MAEM'[ 'MAE': INPUT] 


A similar trick will do a poor man’s validation, by substituting zero for non-numeric 
input: 


MAT*¢SHAPEp:,' 0123456789.0'C! 0123456789. ': INPUT] 


And to do a complete one-to-one mapping from one character set to another (for 
instance when writing out EBCDIC data from an APL application): 


OUTPUT+A TRANSLATE[DAVi DATA] 

Some other handy idioms with dyadic iota include the following: 

@ Removal of duplicates from a vector (either character or numeric): 
VEC+( (VEC 1VEC) =1pVEC) /VEC 


@ Find the position of the first occurrence of A in B: 


POS¢L/BiA 











78 


€ (Membership) 


At this point, my original statement that there was no sensible way to arrange this 
chapter is proved: I have used up all the idioms for ‘membership’ already! Although 
a very powerful function, it is rather specialized and seems less well suited to idio- 
matic use than some of the more primitive components of APL. | 


T (Representation in a Number System, or Encode) 
è Convert any positive number into a vector (e.g. to calculate a check-digit): 
VEC+((L1+100N)p10)TN 
@ Separate a real number into integer and fraction: 
SEP+O 1TNUM 
è Display minutes as hours and minutes: 
OUTPUT+¢240.01x10010 60TITMINS 


è Turn a vector of indices into a ravelled array into the coordinates of points in 
the reshaped form: 


COORD+¢1+(pARR)TIND-1 


(For once I must admit that this looks a great deal neater in zero-origin!) A 
useful application of this idiom is in full-screen management, because IBM’s 
AP 124 returns the ravelled contents of the screen field which you have read. 
If the field in question looks like 





then to find out where the As are: 


+POS¢1+FMT(CFLDNO;3 4)T 1+(INPUT='A! )/i1p INPUT 


1 3 
4 7 


@ Create a truth-table of order N: 
TAB% (Np2)T 1+124N 


| (BaseValue, or Decode) 


This reverses the action of Encode, and the two functions often occur paired, as in 
the hours-minutes example just described. On its own, some of its best uses are as 
follows: 
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è To right-justify a word list: 


RtARJUST M 


[1] aARETURNS A CHARACTER TABLE, 
[2] aALIGNED ON THE RIGHT MARGIN. 


C3] Re(1-(M="' ')11)6M 
v 


This relies on the fact that ‘expression 11’ does a sort of ‘+/a\V from the back: 
10001 0 111 
2 


è Ina similar vein, to strip trailing blanks from a character vector: 


VEC¢(1-(VEC=' ')11)+VEC 
è To evaluate a polynomial, e.g. 8x? + 2x? + 9x +5 (traditional notation) for 
x equal to 10: 
1018 295 


8295 


@ To conserve storage, by packing several vectors into one; e.g. to record the 
activities of 12 crafts, each of which use nine men on a job, for 100 days: 


ADATA¢13 10 1011 ACRAFT,[1] AMEN,(1.5] ADAYS 


Obviously, the packing can be reversed with an equivalent Encode. Personally, 
I dislike this method because (a) it uses a fair whack of CPU; (b) it makes 
ADATA totally meaningless, leading to severe debugging problems. 


@ To perform a ‘scattered point’ selection from an array: 


O+MAT<',' ATAB 'CLUB,DIAMOND ,HEART,SPADE! 


CLUB 
DIAMOND 
HEART 
SPADE 


MAT ASPS 5 2p 41,1 3,2 2,3 5,4 1 
SUITS 


R¢MAT ASPS COORD; SHAPE 


[1] aSCATTERED-POINT SELECTION ON MATRIX OF ANY RANK. 
[2] a<<MAT>> IS THE TARGET ARRAY 

[3] a<<COORD>> IS A TABLE OF REQUIRED POINTS, WITH A 
C4) a COL FOR EACH DIMENSION IN <<MAT>> AND 
[C5] aA ROW FOR EACH POINT TO BE SELECTED. 


C6] SHAPE¢pMAT 
C7] R+( ,MAT)[ (SHAPE. (161 peCOORD ) RCOORD) +1-SHAPE11 ] 
Vv 
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This last is effectively a reversal of the Encode example which deduced the 
coordinates in a ravelled matrix. The skeleton form is: 


POS+¢1 + (pMAT)1COORD-1 


è Finally, a general vector-to-matrix reshape, where I for once have given in to 
zero-origin! 


oMAT+!/,' AARRAY 'FRED,2,XX/JOE, ,Z2ZZ' 
23 4 
MAT(13;3] 


FRED 
2 
XX 


The original of this splendid tour de force is due to Andreas Werder of I.P. 
Sharp (Zurich) and was first seen (in a slightly different style) in the UK APL 
user-group newsletter of December 1979: 


R+DEL AARRAY STR;[1I0;P;SHAPE ;MASK 


zwewxwnwrwrwerwew wwewewwerew lll l å Å å qa — 


[1] aGENERAL VECTOR TO MATRIX RESHAPE. 

[2] aDEL IS A HIERARCY OF DELIMITERS. 

C3] ASTR IS A CHAR VECTOR DELIMITED BY THESE. 
[4] a<< R >> HAS RANK (1+p,DEL) 


[5] O10«0 

[6] R+0,(,DEL)°.=STR 

[7] Pev\((_1+eR)4+1),[£0] R 

[8] Re+\R,COJ~( 1, 14pR)iP 

C9] R+¢R-[\Px 0 “1 +0,R 

[10] SHAPE<«1+[/R 

[11] MASK+«(1i1x/SHAPE )¢«SHAPELR 

[12] R+¢((-pSHAPE)+41)+SHAPEpMASK\! ',STR 


[13] aA SMALL PRIZE IS OFFERED TO THE FIRST PERSON TO 
C14] aEXPLAIN HOW THIS WORKS!! ACDS MAY 80. 


y 


Qand © (Reverse and Rotate) 


Again, I have already used up a lot of the idioms for these; however, there are a 
couple left in the bag: 


è Here is an interesting use of rotate with a Boolean to exchange the arguments 
of any scalar function: 


x#( ..conditional expression..) eA,[0.5] B 
which performs A+B or B*A depending on the condition. 


@ When producing the function listings used in this book, I have used an idiom 
to rotate any labels into the left-hand margin: 
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LAB:STATEMENT 
STATEMENT 
LONGLAB: STATEMENT 
ALOCATE COLONS WHICH OCCUR BEFORE QUOTES OR a'tS 
Ret/V\O<\3=L\ tat! :t.EN 
AROTATE LABELS AND a TO STAND OUT TO THE LEFT 


FN¢R$(-[/0,R¢R+FNC 31J='at )OFN 


X (Transpose) 


This can often be used to refine a result by selecting the meaningful plane from a 
large array of redundant data. 


è An alternative approach to the scattered-point selection (ASPS) is 
1 1 XMAT[1 2431313251) 
SUITS 
è To multiply each row of a table by a vector: 


TAB+1 2 1XMAT° .xVEC 


Both these examples are fine for small arrays, but will really chew up the CPU if 
used indiscriminately! APL isn’t clever enough to know in advance that you only 
want a tithe of the selected data, so it will waste an awful lot of time working out 
redundant figures. 


t and | (Take and Drop) 
For a discussion of branching, see Chapter 4. A selection of other uses is as follows: 
@ Pad an array up to 133 chars for printing: 
MAT+(0 133[pMAT)*MAT 
@ Create a matrix of blanks (zeros) except for the value in one corner: 
MAT<10 804'1! 
@ Create a singleton of rank N: 
(Np0)+ ..scalar 


@ Remove rows D for N from a matrix (i.e. DEL 5/2 in an editor, with DEL 
5/99 meaning ‘to the end’): 


MAT+(~(1+oMAT)+4((D-1)90) ,No1)/#MAT 


è A rather handy little function for teletype dialogues, called STACK, which I 
haven’t managed to fit in anywhere else: 
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CMD¢+STACK STRNG;A 


[1] aAGENERAL PURPOSE COMMAND STACK 
[2] +(pSTK+(L/STK1DELIM)+STK)*BYPASS 
C3] M+STRNG 
[4] STK+(pSTRNG) +, 
[5] BYPASS:STK¢(~A\STKeDELIM) /STK 
C6] CMD+ 1+(L/STKiDELIM)+*STK 

V . 


The usage of this is quite well illustrated in the section on refining the dialogue 
in Chapter 6, or by an example such as 


COMMAND : ALTER/FRED/JOE 1/99,DEL 3/2,FILE 


where a succession of commands is stacked up, separated by commas: 


FN;DELIM;STK;CMD 
C1] aTO TEST COMMAND STACK 
[2] DELIM¢!,* ,STK¢!'t 
C3] JINPUT:+(pCMD¢STACK ‘ENTER COMMAND :- ')+EXIT 
C4] APROCESS COMMAND 
C5] O+CMD 
[6] +INPUT 
C7] EXIT: ‘READY! 

y 


The prompt is only redisplayed when the stack of commands is exhausted. 
Multiple delimiters are ignored, except at the end of an input line; in this case 
a null command is returned, terminating the dialogue. 


E (Domino) 


Not an operator that I personally have used a great deal; however, it does make for 
easy regressions: 


COEFF+BA1 ,(1.5] A 


[...] Indexing 


I suppose this qualifies as a function - anyway, it’s far too interesting to leave out! 
The three idioms given here do little more than scratch the surface, and I’m sure 
you will find that those rather mundane square brackets offer a superb range of 
creative possibilities. 


© Efficient removal of duplicates when a large target vector has a known range 


of positive integer values: 
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INT+999p0 l 
INT[ TARGET ]+1 allowed range is 1-999 


R¢eINT/ipINT 


è A ‘ditto’ function for character tables. This sort of thing can save a lot of 
time in full-screen mode: 


RCH ADITTO MAT;D 


= we ae oF em ee ee ee ee oe we ww ow aw om we a 


[1] aAREPRODUCES PREVIOUS LINE WHEN 'CH! FOUND. 

C2] DI« MATCITE \(~MATV.=CH)x114pMAT; J 

C3] R¢(pMAT)p (DT, ,MAT)(C(1pDT)+(eDT)x,~MATeCH,' 'J 
Vv 


t=! ADITTO FRED BLOGGS ======>> FRED BLOGGS 
= HARRIS FRED HARRIS 


@ Finally, a kind of ‘scattered-point’ assignment, using a combination of De- 
code and Indexing. It is illustrated here by a simple scatter-plot: 


MAT¢Y SCATTER X;SHAPE;POS 


[1] ABASIC SCATTER PLOT OF TWO VARS. 
C2] MAT¢, (SHAPE¢([/Y),[/X)o' ! 
C3) POS¢1+SHAPE1 1+Y,(0.5] X 
C4) MAT[POS]<+'«! 
C5] MAT¢o'+','+', [1] SHAPEpMAT 
y 


Å and y (Grade) 


Grade really is an exceptionally clever and subtle concept. The obvious approach 
would have been to provide a SORT function which, when applied to a vector, 
would put it into sequence. By stopping halfway, grade makes simple ordering 
marginally harder, but in the process provides APL with a marvellous range of 
idioms for ranking, ordering, and selecting. 


@ To start with the obvious one: 
VeVC4AV] or vev[ýv] 
will sort a numeric vector into ascending or descending sequence. 


The beauty of GRADE is that it can be used to rearrange objects other than the 
one from which it was generated, e.g. personnel sorted by age can be achieved with 


PERSONNEL[ 4AGE] 
è To sort a matrix by column N: 
MAT<MAT( AMAT( ;NJ;3] 


@ To sort a matrix by all the columns (treating the left-most as the major key), 
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two approaches are possible. Decode can be used to combine all the columns 
as a vector: 


MAT+MAT(4(0,1+040 1+MAT)1&MAT; J 


e.g. to sort a table of dates (three columns which are respectively YR, MONTH, 
DAY): 

DATES¢DATES[AO 12 311 &DATES; ] 

In this case, the decode radix can safely be embedded in the code, since we 


know in advance the maximum possible range in each column. An alternative 
is to do an iterative sort, taking the least significant key first: 


SORTED¢ANSORTU MAT;GR;COL 


C1] aSORT NUMERIC ARRAY BY COL. 
[2] COL¢(pMAT)[2] 

[3] GR¢114poMAT 

[4] LOOP:*COL+EXIT 

C5] GR+GR[ AMAT[GR;COL]] 

[6] +LOOP ,COL«COL -1 


[7] EXIT:SORTED¢MAT(GR; ] 
v 


Even though this avoids rearranging the data until the last minute, it is still 
slower than the Decode approach. However, there is no other easy way out 
when the value of the encoded keys may exceed 2+31. 


So far, this discussion of Grade has been based entirely on numeric objects. 


Several new implementations of APL have extended its domain to character vectors, 
and even character tables. However, for the moment the rest of us must be con- 
tent with a further shoal of idioms, in which Grade is joined by dyadic iota. 


The collating sequence is often just 


ACSet ABCDE ..essesesse XYZ0123456789', .. odds n' ends 


but not always; it might be ‘CDEFGAB’ for the musical scale; ‘CDHS’ for a hand of 
cards; ‘IVXLCDM’ for Roman numerals; or many other possibilities. 


@ To sort a Bridge hand: 


HAND 


K45QT 
HSCCC 


first by suit 


HAND(E ; Y 'CDHS':1 HAND[2;]] 


4K5QT 
SHCCC 
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then by denomination 


HAND[ ;¥'23456789TJQKA' 1. HAND[13]] 


KQT5S4 
HCCCS 


or by both (denomination within suit) 


MINORAKEY¢Y '!23456789TJQKA' 1.HAND(1 3 J 
HAND[ ;MINORAKEYLY 'CDHS' 1HAND[ 2 ;sMINORAKEY] ] J 


4KQT5 
SHCCC 


e A more usual requirement is a straight alpha sort of a name list. Again the 
Decode approach is fine if you don’t mind a loss of precision after the first 
five or six columns: 


SORTED+NAMES[ 4(pACS)1LACS1iQNAMES; J 


To get over this problem, we could simply revert to a column-by-column sort, 
but why not let Decode bite off as much as it can chew at each iteration? 
Remembering the MAXCOLS idiom: 


GR+CS ACGRADEU MAT;COL;COLS;BASE ;MAXCOLS 


[1] AREASONABLY SLICK MIMIC OF ASCENDING GRADE. 
C2) COL+(pMAT)[2] 
C3] GR+1i1+poMAT 
C4] BASE¢2[1+ pcs 
C5] MAXCOLS¢L BASE®2« 31 
[6] LOOP:>COL+0 
[7] COL¢COL-COLS¢COL| MAXCOLS 
[8] GR¢GR[ABASE1L 14+CS1QMAT[GR;COL+1COLS]] 
C9] +LOOP 
y 


This could either be used ‘in the raw’, or could be called by an alphabetic 
sort routine such as 


SORTED«<AALPHSORT MAT;CS 


C1] aSIMPLE ALPHABETIC SORT 


[2]  CS+e' ABCDEFGHIJKLMNOPORSTUVWXYZ0123456789! 
C3]  SORTED+MAT[CS ACGRADEU MAT; ] 
y 


@ Sometimes we want to sort the rows of a numeric table independently: 
AROWSORT 2 66 31325 5,21%1315 

1233 5 6 

+ 1-233. 5 
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A function to do this is 


SORTED¢AROWSORT MAT;GR;SHAPE 


[1] aSORT EACH ROW OF MAT IN ASCENDING ORDER. 


[2] SHAPE +pMAT 

C3] MAT+¢ MAT 

C4) GReAMAT 

[5] SORTED+SHAPE pMAT([GR[ Af GR#*SHAPE[2]]] 
y 


which uses the second element of the shape as the major key, the data itself 
as the minor key. 


One theme which permeates all this discussion on sorting is the need to avoid 
rearranging data unless this is absolutely necessary. In the context of a dialogue, 
one might have 


SELECT sets up ASEL as the indices of the required data 
SORT rearranges ASEL 
REPORT displays the data, indexed by A SEL 


where SORT, rather than ordering the data directly, simply rearranges a global 
variable which is then used by the REPORT to print/display the data in the required 
order. Obviously, ASEL must be set to a sensible value when the workspace is 


loaded. 
Enough, anyway, of sorting. Other uses of GRADE include the following: 


@ Selection 


VEC(3+¥VEC] the three largest elements of VEC in descending order 
((AYVEC)e.N)/VEC the N largest (in the order they occur in VEC) 
((ASVEC)e1N)/VEC the N smallest 


è Ranking 


AY gives a descending rank vector 


AA gives an ascending rank vector 


This comes in very handy when you want to merge two vectors, using a 
Boolean to interleave the elements: 
VOWELS¢'AEIOUY' <> CONS¢'BSTMSL! 


MERGE+O 11101000110 
(VOWELS ,CONS ) [AAMERGE J 
ABSTEMIOUSLY 


e Reporting. In the foreign currency log I mentioned in Chapter 7, it would 
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be very nice to have the reports sorted by currency, and by amount. Since we 
can’t do both at once, a good second best is to sort by currency, and to 
display the RANK of the amount as an additional column in the report. 


CURRENCY AMNT (STERLING ) RANK 
US. DOLL 3400 3 
US. DOLL 24000 1 
D. MARKS 4000 2 
F. FRANCS 200 4 


TAB+( ACCYREF[CCYPTR;],10 OFAMT,(1.5]J4YAMT) CORDER; J 


Having ground through the primitive functions one by one I now want to 
collect those idioms most relevant to the subject of text-processing. It says some- 
thing for the generality of APL that a notation devised to express complex mathe- 
matical ideas can be so readily adapted to a totally unrelated field. 


@ Set any occurrences of CHARS to blank: 
STR+MASK \ (MASK¢~STReCHARS ) /STR 
STR[ (STReCHARS)/ipSTR]+! 1 


è Chop off leading blanks: 
STR+(V\STR*' ')/STR the neat way 
STR¢(+/A\STR=' ')+STR the quick way 

© Chop off trailing blanks: 
STR¢(1-(STR=' ')11)+STR the pretty way 
STR¢(-+/A\OSTR=' ')¥STR the quick way 

@ Compress multiple blanks: 
STR¢(—14Mnx16M+O,STR=' ')/STR 

© Remove/select text within any paired characters: 
STR¢(~Mv#\M¢STRe'()')/STR remove 
STR+((~M)A¥\M¢STRe'()')/STR Select 

© Insert CHARS in STR before/after the positions flagged by the ones in MSK: 
INS¢( ,MSKe.vO 1)/(2xpMSK)po 1 before 
INS¢(,MSKe.v1 0)/(2xpMSK)e1 O after 


STR¢INS\STR 
STRE (~INS)/1 9 INSJ¢CHARS 


@ Pattern match (i.e. where is SUB in TARGET?): 
POS¢(A#(0,1~1+pSUB)SUB>° .=TARGET) /.1. pTARGET 


or for large strings and big targets: 
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POS¢TARGET ASS SUB;LEN;GR;CT 


C1] AQUICK STRING SEARCH FOR SUB IN TARGET. 
[2] AALL LOCATIONS WHERE SUBSTRING IS FOUND. 
C3] TARGET<¢ , TARGET 

C4) SUB+¢ , SUB 

[5] +(2 1 0 <pSUB)/OK,SINGLE ,EMPTY 


C6] EMPTY :>0,POS¢1 TARGET 
[7] SINGLE:70,PO0S¢(TARGET=SUB)/1pTARGET 


C8] OK:LEN¢Of (pTARGET)-(pSUB)-1 
C9] SUB¢SUB[GR¢Y! ETARINOS'1 SUB] 
C10] GR+GR-1 
C11) >(pPOS+(LEN+GR[1]+TARGET=SUB[1])/1LEN)+0 
C12] GR+«1+GR 
[13] SUB+¢+1+SUB 
C14] CT<+1 
[15] LOOP: +(pPOS¢( TARGET( POS+GR(CT] ]=SUB[CLCT])/POS)+0 
[16] >( (pSUB)2CTeCT+1)4+LOOP 
y 


or to get the row of a table in which a given string occurs: 


POS¢TABLE ASSM STR;SHAPE 


[1] ALOCATE ROW(S) OF TABLE WHERE STRING OCCURS 
[2] SHAPE+pTABLE 

[3] POS+(,TABLE) ASS STR 

[4]  POS+1+SHAPETPOS-1 

C5) ge er ene ea Vena Peay Pn r er te 
Create a word-list from a sentence: 

LIST¢UNIQUE ' ' ATAB ANEATEN INPUT 

Right-justify a word-list: 

LIST¢(1-(LIST=' ')11)$LIST 

Left-justify a word-list: 

LIST¢(+/A\LIST=' ')$LIST 

Remove blank rows: 

LIST+(~LISTA.=' ')#LIST 

Find WORD in a word-list: 
ROW+(LISTA.=(1+pLIST)+WORD) 11 

Sort, using sequence AALPH (39 characters): 
LIST¢LIST(CA391LAALPH1QLIST; ] 

Sort by length of word: 


LIST¢LISTCYLIST+.#' '3] 
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@ Remove duplicate words from list: 
LIST<¢(1 1 &<\LISTA,=QLIST)/LIST 
è Or for lists with many duplicates: 


LIST¢UNIQUE MAT 


C1] ARETURN UNIQUE ELEMENTS IN MAT 
[2] LIST+MAT[ ,13] 
[3] LOOP:>(1+pMAT+(~MATA, =LIST([ (pLIST)(1J;])/#MAT)+0 
Ca] LIST¢LIST,[1] MAT([1;] 
[5] +LOOP 
y 


@ Membership of a new word in a word-list: 


FOUND¢v/LISTA,.=(1+pLIST) +WORD 


@ Dyadic iota on two compatible lists: 
POS¢(<\(AA.=&B),1)F.x11+1+9B 
or if you would rather have zero for elements not found: 
POS¢+/VXO<\BA.=8A 


which is probably the strangest-looking sequence of symbols I can ever 
remember seeing! 


Taken together, these idioms make APL quite unexpectedly powerful in text- 
processing applications. I suspect that, as APL becomes more widespread, such 
idioms will increasingly be taught as a basic part of the language, and will no longer 
need to be re-invented by successive generations of APL programmers. 

That concludes this chapter on idioms and useful functions. I cannot claim to 
have invented much of the material, nor is the list by any means complete; how- 
ever, I hope that by collating it I have made some contribution towards its access-. 
ibility and consistency. The question of efficiency I am deliberately leaving aside 
for the moment; several bits of code will doubtless reappear in Chapter 11 with a 
much deeper analysis of what is going on ‘under the bonnet’. Now a digression into 
a subject which really is (at least as I write this in 1980) new to APL: full-screen 
management. 


Chapter 9 


Full-screen management in APL 


For too long, APL has been a multidimensional notation constrained by a one- 
dimensional view of the world. Even now, life is not perfect: why can’t we just 
treat quad as the screen? 


0£2+13;10+160]«HEADING 
DATA¢Q([10+1103;10+120) 


the damn’ thing looks like a screen after all! One day ...? 

For the moment then, we have IBM’s AP124 and let us try to make the best of 
it. In this chapter I want first to give a general review of screen management with 
AP124, then to tackle in detail the utility functions needed to drive it, and finally 
to make some general points from my own experience of full-screen dialogues. 

First, a short review of what screen management is and does. I am going to refer 
specifically to the IBM 3270 display system (which bids fair to become a de facto 
standard anyway), but I hope that most of this section will be more generally valid. 
The simplest possible case would be to define the whole screen as one 24 by 79 
matrix. (Again, 24 lines by 80 columns seems usual, although wider screens are 
eventually beginning to happen.) Because of the way the 3270 system works, you 
always lose control over the column immediately to the left of any part of the 
screen you define; that is the reason for 24 by 79, not 24 by 80. Into this ‘field’, 
as it is called, you could place a 24 by 79 character matrix, and it would promptly 
pop up on the screen. This is where the fun begins, because as soon as APL has 
finished any function it issues six spaces, as its way of saying ‘Ready’. To display 
these spaces the system has to revert to the standard screen format, so no sooner 
have you created your screen than APL wipes it out for you! The only way round 
this is to pretend that you want to read the screen, as well as to write to it. Then 
APL will wait for you to press ‘Enter’ before it sends out its ‘Ready’ prompt: 


FSMAFMT 1 1 24 79 set up the screen 
1 FSMAW 24 79p'RABBITS ! write data to field no. 1 
DUMMY+FSMAHOLD hold it! 


The details of what the various ‘FSM...’ functions do should become apparent as 
we go along; I shall leave any comments on their innards until the next section. 
In its simplest guise, FSMAFMT takes a four-element vector: 


location of top left of field - row 
- column 
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shape of field - no of rows 
- no of columns 


and defines the screen appropriately. 

FSMAW takes the field number (in this case there is only one) on the left, the 
field contents on the right and moves said contents into the specified field. 
FSMAHOLD waits for ‘Enter’ (or ‘Clear’ or a PF key) and returns a vector indicat- 
ing the numbers of any fields which have been changed. In this case, there can’t be 
any, for reasons about to be explained! 

In addition to telling the 3270 where a field is, and what shape it is, you can also 
define a field’s ‘attributes’ and its ‘intensity’. Those lucky enough to get their hands 
on a 3279 can also play with different colours, of which more later. 

The ‘attribute’ of a field determines whether or not the terminal will let you 
type anything into it. The default is ‘protected’, which means that you can’t. To 
make a field available for input you could either use 


FSMAIN field i.e. FSMAIN 1 
or add a fifth element to the original format vector: 
FSMAFMT 1 1 24790 


where zero means ‘input’ and two is the code for ‘protected’. 
The ‘intensity’ of a field can be 


highlighted code 2 
normal (the default) code 1 
hidden code 0 


Again you could use 
2 FSMAINT fld e.g. 2 FSMAINT 1 

to highlight a field, or you could define it as highlighted with (you’ve guessed it!) 
FSMAFMT 1 1 24 7902 


the sixth element of the format vector. 
One general point before I go on. The only operations which physically (as 
opposed to logically) alter the screen are 


FORMAT (FSMAFMT) 


WRITE (FSMAW) 
HOLD (FSMAHOLD) 
READ (FSMAR) 


Anything else, such as a change of intensity, or positioning of the cursor, only 
actually happens when you do one of the above. It is no use doing 


C1) DUMt¢FSMAHOLD 
[2] FSMACU 1 
[3] INPUT¢FSMAR 1 
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and expecting to see the cursor leap to field 1 ready for you to start typing. To 
achieve this effect, you have to do lines 1 and 2 in backwards order: 


[1] FSMACU 1 store the cursor move 
[2] DUM+FSMAHOLD action the move, and hold 
[3] INPUT¢FSMAR 1 get back the contents of field 


This ‘delayed action’ effect is the cause of frequent confusion, and I would suggest 
that you avoid changing attributes/intensities ‘in flight’ unless absolutely necessary. 
That only leaves 


Cursor positioning (FSMACU) 
Sounding the alarm (FSMABLEEP) 


to worry about. 
What, then, could you usefully do with the knowledge (and functions) I have 
introduced so far? Well a simple text-editor is certainly a possibility: 


NEWTEXT¢EDIT TEXT 


C1] aBASIC TEXT EDITOR 
[2] FSMAFMT 54 1 1 , 24 79 LpTEXT 
[3] LOOP:FSMACU 1 

C4] 1 FSMAW TEXT 

[5] +( pF SMAHOLD) +DONE 

[6] TEXT+FSMAR 1 

[7] +LOOP 

[8] DONE:NEWTEXT+¢TEXT 

[9] FSMACLOSE 


v 


To edit chunks of text wider than 80, or deeper than 24, you might use PF keys 
for scrolling, but the principle is very much the same. Points to note are as follows: 


@ The cursor is moved back to the top left every time ‘Enter’ is pressed. This is 
a good way of showing that the screen is again ready to take input (cf. the 
six-space indent that I mentioned before). 


è If no changes have been made, EDIT assumes this to mean that you have 
finished. 


@ FSMACLOSE simply retracts and expunges the full-screen shared variables, 
which were set up by the initial format. 


By inserting FMT in lines 2 and 4, and AMATEXEC (see later) in line 7 you could 
turn EDIT into a pretty powerful tool for modifying a numeric matrix;a quick OCR 
at the top and DFX at the bottom and, hey presto, a full-screen function editor! All 
this with one field and six utility functions! 

Onward to greater things, and to screens with lots of fields, not just one. I don’t 
actually know what the limit on the number of screen fields is. The highest I have 
ever achieved is 120, which seemed to work happily enough, but anything over 
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50 is getting pretty exotic, and the screen-design functions (Chapter 10) will only 
handle up to 53 fields. Setting up multiple fields is simple enough (Figure 9.1): 


FSMAFMT 3 492 35 2 9, 6 10 10 60, 23 51 22 
1 FSMAW 'A HEADING',9p'=! 
2 FSMAW "DATA 


etc. 


Field 1 





A HEADING 


Lg “iy 
PRONE 





Field 2 






Field 3 





Figure 9.1 


Each row of the matrix passed to FSMAFMT defines a field, just as the vector argu- 
ment defined a single field. Of course attributes and intensities may also be set. 
The fields are referred to by their row index in the original matrix, which may 
incidentally contain rows of zeros; these simply represent unused field numbers. 
So far, so good, but where are the snags? 


@ For screens with more than 10 or so fields, screen design becomes a problem, 
and simple modifications (such as moving fields around) fraught with diffi- 
culty. In fact 1 would never now consider using complex layouts without 
some suitable software to help with panel editing. 


© In its basic form, AP124 takes the ravelled representation of your data, and 
strings it into the appropriate field with no regard for shape. The expression 


1 FSMAW 'A TITLE!,(O.5] t=! 


would result in: 


A TITLE== not A TITLE 


A result not wholly in keeping with expectation! 
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è Every write to the screen (a) eats CPU - around 20 ms minimum, and (b) 


causes the screen to flicker. You can get around this by batching up lots of 
fields into one screen-write: 


1 2 3 FSMAW (6004'A HEADING! ,9p'='),[1] 


etc. The trouble is that every field must be padded up to the ravelled size of 
the largest. Most systems restrict shared storage to around 4K, and it’s astoni- 
shing how easily you can build up to that. In the example above, another four 
fields - even if only of one character each - and 


(17) FSMAW (6004! ........ 
SV SPACE QUOTA EXCEEDED 


or some such helpful message! Again, it’s a case of inventing some helpful 
software, such as (1) 


DRAW ‘fmtname’ 


which would allow panels to be sketched on the screen, moved around, 
deleted, extended, filled with constant text (e.g headings), and given attribu- 
tes and intensities; (2) 


flds FSMAKEEP data 


which would pad up data to the right shape, before either substituting it for 
previously drawn text, or allocating it to an unused field. For multiple fields, 
one row of data would go to each field. Rather than being written to the 
screen, the data would be held in an APL vector, ready for 


FSMAFILL ‘fmtname’ 


which would do a bit of arithmetic to find out the minimum number of 


Component MON TUE WED THU FRI SAT Total 


PRESS «ENTER » to proceed 





Figure 9.2 
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Figure 9.3 


screen-writes possible, and would then display any ‘drawn’ fields which con- 
tained text, and any fields which had subsequently been ‘kept’. 


Before I go into the detail of these, and other, screen-handling functions, here is 
another example of a possible application. In fact it’s the one I referred to briefly 
back in Chapter 6 when I was talking about full-screen dialogues. The object is to 
update a 12 by 18 matrix where each element determines whether a particular 
product can be manufactured on each of the 18 shifts that make up the week. The 
first stage is to draw a suitable format (DRAW ‘FMTBAN’), such as the layout 
illustrated in Figure 9.2. 

Because the fields are sketched on the screen using letters of the alphabet 
(Figure 9.3), it is obviously convenient to use these letters to identify the fields to 
the FSM functions (FSMACU ‘P’, etc.). 

With this slight refinement in mind, the code to maintain this Boolean table 
would look something like 


BAN ; ARR ;MASK 
C1) ACHANGES DEFAULT COMPONENT BANS, 
[2] AWHICH ARE HELD AS ONES IN ABAN. 
C3] FSMAFMT 'tFMTBAN'! 
C4) "At FSMAKEEP AABBR 
[5] MASK+¢54p 1001003100 
C6] LOOP:FSMACU tB! 
C7) ARR¢MASK\!'_X'(1+ABAN] 
C8] ARR[ 3;9x16J¢!|!* 
C9] 'B' FSMAKEEP ARR 
C10) tT! FSMAKEEP 7 O ¥ 12 1 918-+/ABAN 
[11] FSMAFILL FMTBAN 
[12] >( pFSMAHOLD)+EXIT 
[13] ARR¢MASK/FSMAR 'B! 
C14] ABANARR='X'! 
C15) +LOOP 


[16] EXIT: FSMACLOSE 
y 
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I hope this illustrates just how powerful the full-screen management can be. I 
know this wasn’t a particularly difficult task, but compare the amount of code in 
the function ‘BAN’ with that needed to accomplish the same task in teletype mode. 
Because the full-screen version is two-dimensional, we can use the positional infor- 
mation (i.e. just where the user typed ‘X’ on the screen) to deduce the coordinates 
of ABAN into which we must assign zeros. Taking first the user’s view: a screen 
such as Figure 9.2 is clearly vastly easier to use than the most cunningly designed 
‘bottom-line’ approach. Not only does it give an automatic check on the current 
status, but it also allows all the changes to be made in a single transaction. What’s 
more it removes the need for the user to remember the appropriate abbreviations 
for the components he wishes to change. Where data editing becomes more com- 
plex, this ability of full-screen management to deduce information from an entry’s 
position on the screen becomes invaluable. 

Likewise the capability to accept numerous changes at each transaction, and to 
maintain ‘status’ fields which are updated every time ‘Enter’ is pressed. In general, 
the gain in speed for the user is a factor of between 2 and 5 over ‘bottom-line’ VDU 
dialogues; the gain in ease of use is very hard to quantify, but from the enthusiasm 
with which the changeover to full-screen was greeted, I suspect it was at least as 
great. 

Not forgetting the principle of ‘programming by negotiation’, I must now con- 
sider the system designer’s view of the subject! For me, full-screen management 
has been an enormous step forward, and it has widened considerably the range of 
applications which APL can realistically hope to tackle. The principal gains have 
been in the following areas: 


è Economy of code. APL’s matrix-handling really starts to pay off when your 
input data is two-dimensional, and the size of a typical dialogue function may 
well fall by over 50%. 


® Clarity of code. Convoluted expressions to handle stacking or to switch 
between long and short prompts do nothing for functional elegance. 


e Efficiency of execution. What were previously many transactions (even with 
stacking the code still loops) can often be done in one shot. The ‘BAN’ exam- 
ple uses rather less than one-fifth of the CPU taken by its line-at-a-time 
predecessor. 


@ Speed of design. Twenty minutes is a good average to set up a fairly complex 
screen layout. Modification is equally straightforward, and can often be done 
with the user at your side. 


Having enthused for several pages about the marvellous things you can do with 
screen-management, now back to Earth for a look at how some of those FSM func- 
tions actually work. 
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Driving the Screen 


This section deals with the sort of APL functions you will need to make efficient 
use of IBM’s screen management system (AP124). As far as I know, this processor 
makes no distinction between the various VS APL environments (CMS, CICS, etc.), 
so although any functions I quote have only been tested under VSPC and CMS, I 
assume a similar approach will work equally successfully anywhere. 

First, why do we need to cover for the raw shared-variable code in the first 
place? I can think of three main reasons: 


@ It is not particularly easy to remember what the various screen management 
codes do; you may be happy writing 
DATFSM¢5 1 1 


CTLFSM¢1 2 
but on the whole FSMACU ‘E’ seems rather more meaningful. 


@ AP124 is distinctly sensitive about the rank and shape of the objects you pass 
to it. Supposing you wanted to highlight every component where the stock 
fell below some minimum: what if everything is sufficiently stocked? Unfor- 
tunately if you try this with an empty vector of field numbers all you will 
achieve is a rude return code! Whoever wrote AP124 obviously didn’t under- 
stand about null vectors! 


@ It is very easy indeed to do a couple of operations in the wrong order, or to 
forget to reference the control variable where you should have done. This will 
leave the auxiliary processor interlocked, which is not at all a nice situation 
to get yourself (or your user) into. 


I hope that makes it clear that no one in his right mind would contemplate writing 
a serious full-screen application without some suitable software! First, a few design 
criteria: 


© It must take away from the programmer as many of the mundane, time- 
consuming tasks as possible. Things such as checking that fields do not overlap; 
padding text to the correct shape; batching as many fields as possible into one 
screen-write. All these should be done automatically. 


© It must lead to readable, easily understood code at the application level. 


© It must permit easy modification, for example it should be possible to move a 
heading without retyping all the text into it. 


© It should make reasonably efficient use of the CPU, and ought not to clutter 
up the workspace with a horde of extraneous variables or functions. 


The software that I feel goes some considerable way towards fulfilling these re- 
quirements divides naturally into two parts: panel design and panel use. The details 
of the former would seem to fit better in Chapter 10, but to summarize briefly, 


DRAW ‘FMTXXX° 
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creates (or updates if they already exist) two variables: FMT XXX is basically the 
format matrix already introduced, but it includes one additional column (i.e. seven 
in all) which consists of indices into FMTXXXATEXT. This is a character vector 
containing the text held against each field; an entry of zero in column 7 of the 
format matrix implies a field with no text. 


e Each field is defined in the first place by marking its corners with a letter of 
the alphabet A-Z, A, A-Z (53 in all). 


@ Fields may then be moved, extended, deleted, checked for overlap, etc. Attri- 
butes and intensities default to Output/Normal, but may be changed by 
typing T or ‘Z’ or ‘H’ in the top left-hand corner. 


There is one point here on which I differ from IBM’s philosophy - I do not 
believe in the need to attach labels to fields other than the single letter used to draw 
them. I know it makes for extremely easy-to-read code: 


"STOCKS! FSMAKEEP AOSTK 
but I dislike it for the following reasons: 


@ It introduces another variable (FMTXXXALABEL, say). In my view, two is 
one too many, and three is a downright nuisance. 


@ It adds another phase to panel design and I like to keep these things as simple 
as possible. 


@ It makes hard work of operations involving multiple fields: 


'PROD,STOCK,SALES' FSMAKEEP 3 20pADATA 


looks nice, but does take its fair share of CPU in tabulating and looking up the 
name list. Implicit mapping of fields to variables of the same name would also 
be possible, but think of the documentation problems! Variables which float 
from function to function are bad enough, without including the screen in the 
mystery tour. 


Anyway, enough of personal prejudice! If you like the idea of labelled fields, 
then you can very easily adapt the FSM functions to suit. These screen-using func- 
tions fall naturally into five groups: 


@ FSMAFMT and FSMACLOSE, which respectively establish and clear up the 
format. 


@ FSMAKEEP, FSMARESET, and FSMAFILL, which update the held text, and 
move it to the screen. 


èe FSMAHOLD, FSMAPF, and FSMAPFHOLD, which hold the screen and re- 
turn various combinations of information on what the user did to it. 


@ FSMAR, which reads data from the screen. 


è FSMAINT, FSMAIN, FSMAOUT, FSMACU, and FSMABLEEP, which set up 
miscellaneous special effects. 
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Obviously the first thing you must do is to tell AP124 that you want to talk to 
it, and to pass it your screen layout. This might be done by 


FSMAFMT FMTNAME ;FMT;C 


C1) ASHARE FULL SCREEN CONTROL VARS, AND SET UP 
[2] ASCREEN LAYOUT; THEN ESTABLISH FIXED TEXT, 
[3] AISSUE FORMATTING REQUEST AND SET ATT. AND INT. 
C4] +(1=0=1+0pFMTNAME )+NUM 

[5] FMT«2FMTNAME 

C6] ~OFFER 

C7] NUM: FMT¢FMTNAME 

C8] FMTNAME<'AAAA! 

C9] OFFER: FMT+( 2+ 1 1 ,pFMT)pFMT 

C10) >(4=x/C*124 DSVO 2 6 p'CTLFSMDATFSM! ) 40K 
C11) 'NO FSM SHARES! FSMAERR C 

C12] OK: DATFSM+((1+pFMT),4)+FMT 

C13] CTLFSM+1 

C14) +(C+#CTLFSM)+ATT 

[15] 'FAILED TO FORMAT! FSMAERR C 

C16] ATT:>( 1+oFMT+ O 4 +EMT)+TXT 

C17] DATFSM¢ ,FMT[ 31] 

C18] CTLFSM+6,11+p9FMT 

[19] JINT:>( 1+pFMT+ O 1 VEMT)+2XT 

C20] DATFSM¢ ,FMT[ 31] 

[21] CTLFSM¢7 ,11+9FMT 

[22]  TXT:>(xŪNC FMTNAME,'ATEXT!)4STORE 

[23] FSMAKEEP+,! ! 

[24] >DONE , FSMAPTR¢(1+pFMT) pO 

[25] STORE: FSMAPTR¢FMT[ 32] 

[26] ¢'FSMAKEEP¢! ,FMTNAME, 'ATEXT! 

C27] DONE: 


y 


Lines 4-8 make the distinction between a named format (FSMAFMT ‘FMTXXX’) 
and a simple numeric argument (FSMAFMT 1 1 24 79); if the latter, line 8 sets up a 
dummy name, for reasons soon to become apparent. Lines 9-15 offer the shared 
variables, and set the basic format. (FSMAERR simply displays a suitable error 
message and does a bare right arrow to terminate any calling functions.) Lines 16-18 
use column 5 (if it exists!) to set the attributes, lines 19-21 set the intensities similarly. 
Then for the fixed text, and now we see the reason for that highly improbable 
name on line 8! Two temporary globals are set up - FSMAPTR and FSMAKEEP - 
which start life as simple copies of column 7 of the format, and the associated 
ATEXT. If this text variable does not exist (i.e. the format was not set up through 
DRAW, or no text was defined) then FSMAPTR and FSMAKEEP are simply initial- 
ized (lines 23 and 24). 
To get rid of this motley crew of shared and unshared variables, 


FSMACLOSE;A 


[1] amRETRACT FULL-SCREEN VARS, AND ERASE SAME. 


[2] A+OSVR 2 6 p'CTLFSMDATFSM'! 
C3] A+QEX 4 8 p'CTLFSM DATFSM FSMAKEEPFSMAPTR ! 
Vv 
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But before we do that, we obviously want to put them to work! This brings us to 


FLDS FSMAKEEP MAT; FMT; SHAPE ;C ;NEWFLDS ;MAX 


C1] ABUFFER UP SCREEN FIELDS FOR MULTIPLE WRITE. 

[2] 2(~0=140pFLDS)/'FLDS<1[~ 65+QAVi(FLDS#'!' *')}/FLDS! 
C3] CTLFSM¢9 

C4] +(C+CTLFSM)+FAIL 

C5] +(FLDSV .>1+pFMT<DATFSM)+OK 

[6] FAIL: ‘KEEP FAILED! FSMAERR C 

C7] OK:MAT+(_ 24 1 1 ,pMAT)pMAT 

C8) +(1=eFLDS+¢,FLDS)+MULT 


C9] SINGLE:MAT¢(1,x/pMAT) pMAT+FMTCFLDS[1]; 3 4]+MAT 
[10]  MULT:SHAPE+x/FMT[FLDS; 3 4] 


C11] +(V/NEWFLDS¢O=FSMAPTR[[FLDS])+REP 

C12) APAD OUT FSMAKEEP TO ACCEPT NEW FLDS. 

C13] FSMAPTR[NEWFLDS/FLDS]+(pFSMAKEEP)++\0, 1+NEWFLDS/ SHAPE 
[14] F SMAKEEP¢FSMAKEEP, (+/SHAPExNEWFLDS)p! ' 

C15] ANOW SUBSTRING TEXT INTO FIELDS. 

C16] REP :MAX+¢i1+pMAT 

C17] FSMAKEEP[ 1T , (SHAPE° .2MAX)xFSMAPTR[FLDS]e .+MAX]«,MAT 


Basically what this does is to modify two globals, FSMAPTR and FSMAKEEP; how- 
ever, there are one or two slight refinements! Line 2 simply translates field letters 
(‘BCD’ FSMAKEEP . . .) to the corresponding field numbers. Lines 3-5 find out 
what the current format is, and check that all requested fields fall within it. What 
happens now depends on whether a single field is being kept, or if FLD isa list of 
several. Line 9 ensures that the content of a single field is sensibly padded to the 
right, and down, i.e. 


'At FSMAKEEP 'TITLE!',[0.5]'=' 


whereas multiple fields are simply padded to the total size of the corresponding 
area on the screen (line 10). Line 11 checks whether there is any fixed text held 
against the field, or if something has already been kept there. If so, the pointer is 
left as it was and the appropriate chunk of FSMAKEEP is over-written. Otherwise 
the pointer is set to the end of the current text and the new text is strung on to 
the back of FSMAKEEP. 

As a momentary respite from the rigours of all this rather heavy APL; to set the 
text back to the drawn version, 
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FSMARESET FMT 


[1] ASET SCREEN BACK TO DRAWN VERSION. 


[2] FSMAKEEP¢sFMT,'ATEXT! 
[3] FSMAPTR¢(2FMT)C37] 
Vv 
which successfully undoes all the hard work of FSMAKEEP. 
The next obvious requirement is to get all that stored text up on the screen; to 
do this we could use 


FSMAFILL FMT;RANK ; THISLOT ;MAT  ;MAX;C 


C1) AWRITE HELD FIELDS OUT TO SCREEN. 
[2] s (~0=1+0pFMT)/'EMTesFMT' 
C3] RANK¢}¥x/FMTC; 3 4] 
C4] >( pRANK<(xFSMAPTR[ RANK ] ) /RANK ) +0’ 
[5] NXT:MAX¢x/FMTCRANK(1]; 3 4] 
[6] THISLOT¢( ( pRANK)LL4070+MAX ) +RANK 
[7] MATFSMAKEEP[ (pFSMAKEEP)LFSMAPTR[THISLOT]”. +1MAX] 
C8) DATFSM¢MAT 
C9] CTLFSM¢2 , THISLOT 
[10] >(C+' tpoCTLFSM)+OK 
[11] 'FIELD NOT WRITTEN! FSMAERR C 
[12] OK:>( pRANK<¢(pTHISLOT)+RANK)tNXT 

y 


No matter how complex the screen, lines 3 and 4 ensure that two screen-writes will be 
enough to display it; fields are first ranked in order of size, so that the best possible 
use is made of the available 4K of shared storage. The biggest field determines the 
number that can be dealt with first time around (of course it may be all the fields), 
and line 6 holds the field numbers to be taken. Lines 6 and 7 select the correspond- 
ing text from FSMAKEEP (padded up to the size of the largest field, and shaped 
appropriately). It doesn’t matter at all that the text for the smaller fields is padded 
up with whatever comes next in FSMAKEEP; this padding never actually makes its 
way on to the screen. Finally, the padded field contents are passed to AP124, and 
the fields are written on the screen. If necessary (i.e. there are still some fields 
remaining) it now loops back to repeat the process. 

That basically covers the ways of getting data up on the screen; however, for the 
sake of completeness I shall include 


FLD FSMAW CHARS;C 


C1] aAWRITE TO GIVEN LINE(S) OF SCREEN. 

[2] ¢(~0=140pFLD)/'FLD¢1f~ 65+DAVi (FLD! '!)/FLD! 
C3] >(1 0 =pFLD+¢,FLD)/SINGLE,O 

C4) CHARS¢( 24+(pFLD) ,pCHARS) pCHARS 

[5] DATFSM+CHARS 

C6] >VRITE 


[7] SINGLE: DATFSM¢,CHARS 

C8] VRITE:CTLFSM¢2 ,FLD 

C9] >(C¢! !oCTLFSM) +0 

[10] 'FIELD NOT WRITTEN! FSMAERR C 
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This can be used independently of the ‘keep-fill’ approach to write data directly 
to screen fields. Its only slight subtlety is line 4, which allows single lines of text 
(e.g. ERROR’) to be written to several fields at once. 

The next group of functions (FSMAHOLD, etc.) are concerned with holding the 
screen you have just created; which one you will want to use depends on the infor- 
mation you want to be returned to you. Several other permutations are possible 
as well - you might like to discriminate between ‘clear’ and ‘enter’, or to find out 
where the cursor had been left. The principle is the same: 


R¢FSMAHOLD ;C 
C1) AHOLD SCREEN DISPLAY. 
[2] CTLFSM¢3 
C3] >((C+DATFSM)C1Je O 1 5)+*0OK 
C4) 'HOLD FAILED! FSMAERR C[1] 


[5] OK:Re5+C 
y 


This tells you which fields have had something typed into them, e.g. if your user 
has modified fields ‘A’ and ‘R’, 


FSMAHOLD 
1 18 
If he has changed nothing at all (or has pressed ‘clear’), then 


>( pFSMAHOLD ) + DONE 


is a very convenient way of detecting the fact. 


R+FSMAPF ;C 


[1] AWAIT FOR INPUT, CHECK THAT A PFKEY WAS 
[2] AUSED, AND RETURN NUMBER OF KEY. 
C3] aCLEAR AND ENTER BOTH RETURN 0. 


C4] CTLFSM¢3 
[5] C<+2+DATFSM 
C6] Rex /C 

y 


does a similar job, but tells you instead which PF key was pressed. 


R¢FSMAPFHOLD;C 

C1] aWAIT FOR INPUT; IF A PFKEY WAS USED RETURN NO OF KEY 
[2] AOTHERWISE CLEAR AND ENTER BOTH RETURN 0. CATENATE 
C3] aTO THIS THE NUMBERS OF ANY MODIFIED FIELDS 

C4] CTLFSM¢+3 

[5] +((C#DATFSM)[1Je 0 1 5)+0K 

C6] 'HOLD FAILED! FSMAERR C[1] 


[7] OK:Re(x/2tC) ,5+C 
Vv 
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combines the functions of both the above. The first element tells you which key 
was pressed, and there are as many remaining elements as there were fields modified. 


Having 


held the screen, and determined that the user has typed something, the 


next requirement is to retrieve the altered data: 


C1) 
[2] 


C3] 
C4) 
E53 
C6] 
C7] 
C8] 
C9] 
C10] 
C11) 
C12] 
C13] 
[14] 


DATA*¢FSMAR FLD3;C;SHAPE 


AREAD SPECIFIED FIELDS INTO DATA WITHOUT 
AWAITING FOR ENTER OR PFKEY. 


2(~0=140pFLD)/'FLD<1f° 65+0AVi1(FLD#!! 't)/FLD! 
CTLFSM¢5 , FLD 
>(C+¢' !pCTLFSM)4FAIL 
DATA«+DATFSM 
>(1=p,FLD)+0 
CTLFSM<¢9 
>(C+!'tpCTLFSM)+4FAIL 
SHAPE*«DATFSM 
SHAPE+(SHAPE[1]=1)+SHAPE+,SHAPE[FLD; 3 4] 
+(1=ppDATA+SHAPEpDATA)+0 
+0 ,eDATA<(1-(DATAe! _')11)4+DATA 
FAIL: 'DATA NOT READ! FSMAERR C 
y 


For multiple fields this simply reverses the action of the screen-write, and returns a 
padded matrix with one row per field. Single fields are reshaped (lines 8-12), and 
vector fields have trailing blanks (or underscores) stripped off (line 13): 


pDATA+FSMAR +-------------- + 

| FRED BLOGGS | 

| JOE SOAP | 

| | 

$e eee + 

3 15 
$------- +--+ + 
eDATACFSMAR |ADRIAN SMITH | 
t-----~-------------- + 
12 (not 20) 


From the point of view of full-screen applications, it is a great shame that APL’s 
execute function works only on vector arguments. This restriction leads us into 


things like 


[1] 
[2] 
C3] 


C4) 
C5] 


C6] 


C7) 
C8] 


OUT+AMATEXEC MAT;ENT;MASK;ZERO;RHO;P 


AEXECUTE CHARACTER MATRIX, 
AREPLACING INVALID CHARS WITH ZERO. 
A 


MAT<+'1234567890 +|_.~-'iMAT 
RHO¢pMAT+! ',(11234567890 _.~-O'[CMAT]),! ! 


ACHOP OUT MULTIPLE UNDERSCORES 


MASK¢~(MAT=!_')A1OMAT=! ! | 
MAT+¢RHOp(,(+/MASK)°.2.1 1*eMAT)\(,MASK)/,MAT 
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C9] aCHOP OUT MISPLACED NEGATIVE SIGNS 
C10] MASK¢(MAT#'~ ')v(MAT=""~ ')a(1OMATe!1234567890.'!)A 16MA 
C11] MAT+RHOp(,(+/MASK)°.21 1+pMAT)\(,MASK)/,MAT 


[12] ACHOP OUT MISPLACED DEC. POINTS 


C13] MASK¢(MAT#!.')v(MAT=!..')A1OMATeE'1234567890! 
C14) MAT«(,(+/MASK)°.21 1*oMAT)\(,MASK)/,MAT 


C15] AFIND REMAINING UNDERSCORES 
C16] MASK¢('_'=MAT)/1eMAT 
C17] AREPLACE THOSE ON THEIR OWN BY '0! 


C18] ZERO+( (MATCMASK+1J=' ')AMATCMASK-1]J=' ')/MASK 
C19) MAT(ZEROJ]<«'0! 


[20] AAND ANY OTHERS BY BLANKS 


[21] MAT( (~MASKeZERO)/MASK]J<+! ! 
[22] MAT<RHOpMAT 


[23] ACOUNT HOW MANY NUMBERS PER LINE; 
[24] ASKIP THE è IF NONE ANYWHERE. 


C25] >( (OUT¢0)A. =ENT++/MASKA1$~MASK*MAT=! ')/SK 
[26] AREMOVE MULTIPLE DEC POINTS FROM EACH NUMBER 


[27] MAT+(~PMAT=' ')/MAT«,(MAT),!' ! 
[28] MAT<' ',(pP)p(,P+P°.21f/0,P«+(xP)/P+P-1+0, 1+P+P/ipP) 


C29) AEXECUTE AND EXPAND TO CORRECT SHAPE 


c30] OUT+( ,ENTo .2>1f/,ENT)\2(,(MAT#!.')v<\MAT='.')/ MAT 
C31] SK:OUT«((pENT) ,[/0,,ENT)pOUT 
y 


the action of which is best illustrated by 


+DATA-AMATEXEC _20 3 5 
XX 5.6 


Basically it makes the best sense that it can of the screen. Invalid characters are 
replaced by zeros, as are blocks of contiguous underscores. Each row is padded to 
match the row with most entries in it; each plane likewise if it is called with an 
argument of more than two dimensions. 

To reverse the effect (i.e. to display a matrix on the screen in a form suitable 
for updating): 


R+FMT DFMT MAT;POS;SHAPE;WID; ZEROS ;MASK 


[1] aFILLS DATA FIELDS UP WITH UNDERSCORES FOR F.S. DISPLAY 
[2] ARANK OF RESULT IS SAME AS RANK OF RIGHT ARGUMENT. 


C3] 
C4) 


C5] 
C6] 


[7] 
C8] 
C9] 
C10) 
C11) 
[12] 


[13] 
C14) 


C15] 
C16] 
C17] 
[18] 
[19] 
[20] 
[21] 
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MAT+((-2[ppMAT)+ 1 1 ,SHAPE<pMAT) pMAT 
AEXTEND FORMAT STRING AS NEEDED 


EFMT+(2x[0.5xp,FMT)+FMT 
FMT«(( 14 oMAT) ,2) FMT 


aAREMEMBER SHAPE FOR FUTURE REFERENCE. 
SHAPE<(~1+SHAPE), 1+pR+(,FMT) *MAT 

aCHECK FOR LARGEST FIELD. 

WiIDe«.1[f/FMTC 31)-1 

aFIND THE PLACES CORRESPONDING TO ZEROS IN MAT. 
ZEROS+,&(([/0,WID) ,p ,MAT) pMAT=0 


AFIND REMAINING FIELDS IN RAVELLED STRING. 
aFIELDS OF WIDTH 1 GET FILLED IN THEIR ENTIRETY. 


POS«+(~142++\0,FMTC 31])°.+WID-1[3-pWID 
POS+(MASK+, (1 FMTE31]-1)°.2WID)/,POS 
ZEROS+«( (ZEROS) pMASK) / ZEROS 
POS¢,((0,1-1+x/ 14pR)x 14eR)°.+POS 
R¢,R 

RC (ZEROSV' '=R[POS])/POS]+'_! 
R«+SHAPEpR 







6 O DFMT DATA 








Between them, these two functions provide the basis for any application which 
involves editing numeric data. (Those of you with a OFMT should be able to con- 
coct DFMT rather more efficiently.) 

Finally, a group of miscellaneous functions to do those occasional odd jobs not 
covered so far: 


INT FSMAINT FLD;C 


C1] 


C2] 
C3] 
C4] 
C5] 
C6] 
C7] 


ASET GIVEN FIELDS TO REQUIRED INTENSITY 


+(0=9,FLD)+0 

2(0=0=140pFLD)/'FLD¢1f 65+0AVi(FLDe't'! '!)/FLD! 
DATFSM<0[ 2L INT 

CTLFSM¢7 ,FLD 

+(C«+CTLFSM)+90 

'FIELD MOD FAILED! FSMAERR C 


y 


changes field intensities, for example to highlight components out of stock, or over- 
loaded machines. 


C1] 


C2] 
C3] 
C4) 
C5] 
C6] 
C7) 


FSMAIN FLD;C 


ASET GIVEN FIELDS TO ACCEPT INPUT 


+(0=9,FLD)+0 
2(0=0=14+0pFLD)/*FLD¢1[~65+0AVi(FLD#'' '')/FLD! 
DATFSM+0 

CTLFSM+¢6 ,FLD 

+(C+CTLFSM)+0 

‘FIELD MOD FAILED! FSMAERR C 
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and 


C1] 


C2] 
C3] 
C4] 
C5] 
C6] 
C7] 


FSMAOUT FLD;C 


ASET GIVEN FIELDS TO REFUSE INPUT. 


+(0=9,FLD)+0 
¢(0=0=1+0pFLD)/'FLD«1f~65+0AVi(FLD#'! 't)/FLD! 
DATF SM¢2 

CTLFSM+6 ,FLD 

+(C+CTLFSM)+0 

'FIELD MOD FAILED! FSMAERR C 


change the protection of fields; for example certain users may not be allowed to 
update particularly critical information, at least until they have supplied a pass- 
word. The appropriate fields can then be unlocked. 


[1] 


[2] 
C3] 
C4) 
C5] 
C6] 
C7] 
C8] 
C9] 


FSMACU FLD;C 


ASET CURSOR POS. DEFAULT IS START OF FLD GIVEN, 


¢(~0=1+0pFLD)/'FLD¢1F 65+OAVi(FLD#'!' '')/FLD! 
+(4Le,FLD)$60,21,L22,WR 


:3WR,FLD¢FLD, 1 1 
:FLD¢FLD[1],1,FLD(2] 
: DATFSM¢FLD 


CTLFSM¢12 
>(C+CTLFSM)+0 
'CURSOR NOT SET' FSMAERR C 


gets the cursor to where you want it. It assumes ‘top left’ unless you specify other- 
wise, in which case you have to use the field number, rather than letter. 


C1] 
[2] 


FSMABLEEP 


ASOUND BLEEP AT NEXT SCREEN I/O. 


CTLFSM+11 


Vv 


is self-explanatory. If your screen doesn’t have an ‘audible alarm’ it obviously won’t 
make any noise, but neither will FSMABLEEP actually fall over. 

That concludes this section on ‘Driving the Screen’. I have, for once, included 
a lot of detailed code. This is not because I’m particularly proud of it, on the con- 
trary, many of the functions were put together in rather a hurry and can doubtless 
be improved upon. Rather I wanted to illustrate the sort of problems one comes 
up against when handling a full-screen application, and to show that they can be 
overcome without an enormous amount of effort. I now want to move away from 
the nitty-gritty of CTLFSMs and DATFSMs for a few closing thoughts on: 
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What Makes a Good Full-screen Dialogue? 


There are two important things to get right: (a) the design of each screen and (b) 
how the screens are linked together. 

The design of individual screens is obviously more an art than a science, and does 
depend heavily on the nature of the application. Some of the points which seem to 
me to be generally valid are as follows: 


@ Put the most commonly used fields somewhere near the middle. 


e Don’t use highlighting for small fields, unless they are tucked away in the 
corners. One highlighted field in the wrong place can make it virtually im- 
possible to concentrate on several nearby fields. 


@ Where there are several similar-looking screens (e.g. ADD, UPDATE, and 
DISPLAY) which do different jobs, make it obvious (e.g. with ‘DISPLAY’ 
highlighted top right) which is which. 


@ When a transaction is complete (e.g. some data has been updated) this too 
should be made clear, and the message should be left on the screen until 
the next action by the user. 


@ Make sure that the layout uses the tab keys sensibly. Tabbing across fields 
is easy in the 3270 system; tabbing down column fields is not. If necessary 
you can always transpose your data to ensure that the ‘natural’ sequence is 
also the convenient one. 


© Leave the bottom line (or two lines) free for assorted help messages, e.g. 
PF 10 for Stock Position, ‘ENTER’ for Full Menu 


@ As in the example above, use lower-case letters to help reduce the emphasis 
of descriptive fields. Lower case is definitely more readable for complete 
‘help’ screens. 


@ Don’t overcrowd screens. Either use PF keys to switch formats, or leave 
‘occasional’ fields at zero intensity, again using a PF key as an ‘on-off 
switch. 


The user should be able to switch from anywhere to anywhere within a series of 
related screens without reverting to a menu each time. When first invoked, the root 
function should go straight to the most commonly used screen of the set, not to the 
menu. For example, in a production scheduling system, an editor might create 
displays to (a) change the production plan; (b) display a projected stock; (c) display 
required components; (d) change some basic parameters, such as shift-level or 
number of machines available; (e) display a menu of the above four options. Assum- 
ing PF1 to PF4 for the four stages (a)-(d) above, PF12 to quit, and ‘ENTER’ for 
the menu, such an editor could be driven by 
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EDITOR; LAB ;ACTION 
C1) aDRIVER FUNCTION FOR SCHEDULE EDIT 
(2) +14+LAB«¢MENU , PLAN, STOCK ,COMP , PARM, (7pMENU) ,QUIT 
[3] MENU : ACTION¢EDAMENU 
ray LKP:>LAB[1+ACTION] 


[5]  PLAN:>LKP,ACTION+EDAPLAN 
[6] STOCK:>LKP,ACTION+EDASTK 
[7] COMP:+LKP,ACTION+EDACOMP 
[8]  PARM:>LKP,ACTION+EDAPARM 
C9]  QUIT:'EDIT CLOSED! 

y 


Each function in the set would be something like 


ACTION¢EDAPLAN ;CTL 
C1) AEDIT CURRENT PRODUCTION SCEDULE 
[2] FSMAFMT 'FMTEDAPLN! 
[3] A 
C4] A 
[5] +(1=pCTL«¢FSMAPFHOLD ) +DONE 
[6] A 
[7] A 


C8] DONE:ACTION¢CTL[(1] 
V 


Figure 9.4 shows one way of representing the dialogue diagrammatically. 

This approach has the great advantage that an experienced user can drive the 
system efficiently, but a novice is never more than one keystroke from the menu, 
or from APL. There is nothing more frustrating to a user than knowing where he 
wants to be in the system, and having to plough through a tree of menus to get 
there; by building in short cuts you both save his time, and save CPU time. 

If response time is a problem, it is a good idea to throw out an immediate 
‘interim response’ into the message field at the bottom of the screen (e.g. 
‘***PFKEY 4 accepted: please wait’). This will at least delay the point at which the 
user starts pummelling the keyboard! 

That really covers all I want to say on full-screen dialogues. To restate some of 
the most important points: 


@ The screen is two-dimensional, so take full advantage of the positional infor- 
mation. 


@ Remember the APL philosophy of parallel processing; plonk everything on 
the screen and read it all back. Don’t mess around taking in one field each 
time ‘enter’ is pressed. 


© Get yourself some decent software for screen design and screen use. 
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Figure 9.4 


@ PF keys are a much better way of driving a series of screens than trees of 
menus. 


There remains the intriguing possibility for the future - colour. Many planning 
applications would undoubtedly benefit greatly from the judicious use of colour 
screens, and I look forward with considerable anticipation to the day when a book 
such as this will routinely include a chapter on the use (and abuse!) of colour 
graphics. 

As it is, APL has at long last been granted an input device worthy of its multi- 
dimensional notation. In the long term this may well be the second crucial factor 
(file-handling being the first) which will open the gates to an enormously increased 
range of applications. If this is so, it will not be long before even the most produc- 
tive APLer is under pressure, and it is in answer to his needs that I move on to soft- 
ware which is aimed not at the user, but at the programmer himself. 


Chapter 10 


Software for development 
and documentation 


This chapter is aimed primarily at professional and semi-professional programmers 
who are using APL to build substantial commercial systems. As befits a pure con- 
cept which has lain unnoticed in the backwaters of commercial computing, APL is 
blessedly free of so many of the sales-inspired ‘enhancements’ that have been 
thoughtlessly tacked on to other systems. This freedom has its price, however, in 
that many facilities which professional programmers take for granted are conspicu- 
ously absent from most APLs. When it comes to things like formatting and input 
validation, file-handling and system commands, the APL bureaux have been falling 
over each other in their eagerness to supply all the goodies which they know attract 
customers. IBM, on the other hand, have been quietly marking time; their APL\360 
became APLSV, and now VS APL, all with very little by way of commercial en- 
hancement. 

Having done all my APL on these IBM systems, I have no direct experience of 
the joys of OFMT, OVR, etc., or of the concept of ‘component files’ which the 
bureaux have pioneered. The formatting function is one which catches me very 
much in two minds: on the one hand it strays a long way (both in form and pur- 
pose) from the original purity and consistency of APL; on the other hand it does 
provide professional programmers with the kind of tool they expect to find in a 
commercial environment. Never having had OFMT, I personally don’t miss it, but 
I’m sure there must be very many ex-bureau systems which have acquired hastily- 
written AFMT functions to cover a move in-house. To all these people (and those 
anticipating such a move) I apologise - there is no AFMT to be found here, because 
I have never seen a good one. It’s the kind of task that just doesn’t seem to square 
with APL’s philosophical base, which is probably why IBM haven’t given us a 
OFMT in the first place. Until they do, my advice to bureau users would be to use 
OFMT where it is necessary, not where it is convenient. Otherwise they may find 
themselves tied much more firmly to the bureau than they had anticipated! 

The second major contribution which the bureaux have made to ‘commercial 
APL’ is the idea of component files, and here the VS APL user can follow, albeit 
slightly clumsily. 

This is another area where there would be little point in my giving detailed code, 
because the shared variables of VS APL are used very differently in the assorted 
environments. For example under CMS you can safely use files of APL objects writ- 
ten and read without conversion; under VSPC such files are available but are much 
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less convenient, and waste a great deal of space. What I think you should do is to 
bury all file access under cover functions which follow the principles of the ‘com- 
ponent file’ system. Not only does this make the code more readable at the appli- 
cation level, but it also insulates you from a change of environment, and ensures 
that the file access is done as efficiently as possible. The typical form of these cover 
functions is 

RC+ .. filename .. FUNCTION .. variables .. 


or 


RCFUNCTION .. filename 
If you follow the naming conventions established by the bureaux, 


>(RC¢AFCREATE 'MYFILE')+FAIL 


Or 
+(RC+'MYFILE' AAPPEND 'ADATA!)*FAIL 


etc. 
Two additional functions which I find useful are 


RC+'MYFILE' ADUMP 'ADATA ADESCR ATABLE' 
and 
RC¢'MYFILE' AGET 'ATABLE ADATA! 
RC+'MYFILE!' AGET '! 


The first of these creates (or overwrites) the file ‘MYFILE’ with all the variables given 
in the list. The second retrieves either selected variables or the entire contents of the 
file. These functions are particularly useful where you have a system broken down 
into several workspaces, which pass information to one another in the form of APL 
variables. If you can design a batch program to take conventionally structured data, 
and invert it to the same format as your component files, then you have a very 
powerful tool indeed for data enquiry. 

File access is a subject where the ‘tricks of the trade’ depend heavily on the way 
your particular APL has been set up, and I can’t really offer any more constructive 
advice here. I now want to move on to look at three topics, all relevant to the aim 
of making life easier for the APL programmer: (a) a decent editor for functions and 
variables; (b) a design and editing system for full-screen panels; (c) functions to 
automate workspace documentation. The first two of these are aimed specifically 
at screen-based systems, the third is more generally applicable. 


Full-screen Editing for Functions and Variables 


Even on a teletype the V editor always struck me as being somewhat feeble-minded; 
on a VDU it is utterly inadequate, and should have been replaced long ago. Rumour 
has it that the next release of VS APL does have considerably better editing, but I 
still think it worthwhile to run through the main characteristics of a good screen- 
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based function-editor. It is interesting to note that a function to achieve these 
breaks virtually every convention in Chapter 5! My version is called ‘A’: it is (at the 
last count) 171 statements long, branches to line numbers, is totally uncommented, 
and uses distinctly non-mnemonic three-character local names. For a function like 
this, the criteria on which the code is judged are very different from the usual: it 
must be compact, efficient, economical in its use of symbols, and easily copied and 
erased. By creating a 171-statement megalith you achieve all of these; in fact ‘A’ 
makes only 28 symbol-table entries, and occupies just under 10K of workspace. Of 
course there is a parallel version which is commented and branches to labels, and 
this is the one that gets amended, before being stripped down to the production 
version. Enough, anyway, of this digression. What should a reasonable full-screen 
editor do, and how should you set about writing one? Oddly enough, the first half 
of the problem is very much the hardest part - the actual coding is tedious rather 
than difficult. Obviously the design of my editor has evolved over a long period, 
and it is still averaging one change every couple of months or so. As I write, its 
functional specification goes like this: 


@ It will edit functions (as long as they are not suspended) and character 
matrices, up to 135 characters wide, and up to 500 lines long. 


@ You can move from function to function, function to variable, etc., without 
leaving Edit. When leaving an object you can either ‘SAVE’ and preserve the 
changes you have made, or ‘QUIT’ to leave it as it was. 


@ The size of the screen window is 20 lines by 71 columns, and can be scrolled 
horizontally and vertically (Up, Scroll, >, <). 


@ On this window, you can overtype any line, or add new lines up to 12 at a 
time (see Insert); erase a line, by pressing ‘ERASE EOF’ at the start of it 
(functions only); restore the window (CLEAR); put it back into the fn/var, 
and return the cursor to the command area (ENTER). 


So far, this is all easy stuff, and it covers 95% of the actual use of ‘A’. However, 
there are some operations which can’t easily be done in full-screen mode (e.g. Move, 
or the replacement of one string with another throughout a function), so in the true 
spirit of Pareto’s law, the remaining 95% of ‘A’ only does about 5% of the work! In 
fact the reason it has such a full range of editing commands is largely historical; it 
was originally written under CMS before we had AP 124 and I wanted to make it 
look as similar to the CMS editor as I could. The command area of the screen is 
50 characters long, and will accept any stack (separated by commas) of commands. 
In case of any unrecognizable (or impossible!) command, the culprit is displayed in 
a highlighted field, and the rest of the stack is cancelled. Most of the commands 
only need an initial letter (e.g. ‘T’ will do for ‘TOP’), so here they are, with a note 
on the amount of code needed to do each one: 
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Command 


Example 


Lines of APL 


Result 





ke) 


12 


Centres window on line 12, and 
puts the cursor there 


T,B,S,U,N N5 One each Moves window around vertically 

Locate L EXIT 4 Finds next occurrence of ‘EXIT’ 

Insert p I5 6 Leaves 12 blank lines after line 5, 
and puts the cursor on the new 
line 6 

Ip text I6 COMMENT 4 COMMENT becomes line 7 

DELete p/n DEL 5/6 9 Removes lines 5 and 6 

Move p/n M 4/7 10 Lines 4-7 are moved to follow the 
line currently in the middle of the 
window 

Alter A FRED/JOE 26 Replacement of character string. 

1/99 ‘Alter’ does this regardless of con- 

Replace R IN OUT 5 text; ‘replace’ only changes valid 
APL names, i.e. it won’t touch ‘IN’ 
in the middle of ‘PRINT’ 

Get object G EDIT 5/6 15 Lines 5 and 6 of ‘EDIT’ are inclu- 
ded after the current line 

G5 Line 5 of the function being edited 

is included after the current line, 
i.e. it is duplicated 

Width n w90 4 Changes function width, e.g. to 
allow a longer header to be typed in 

Width W 1 Displays current width 

STAck char STA! 2 Temporarily makes ‘!’ the stack 


delimiter | 





Because of its ‘current line’ heritage, ‘A’ still maintains a pointer to the centre 
line of the window, and shows this with an arrow at the side of the function. All 
the commands assume ‘current line only’ as the default, e.g. ‘DEL’ just deletes the 
arrowed line; ‘I COMMENT’ would make the next line ‘COMMENT’, etc. Because 
‘A’ always moves the arrow to the line where you left the cursor, you can do com- 
mands like ‘Move’ very easily, by typing the command, putting the cursor on the 
destination line, and pressing ‘Enter’. 

I would say the biggest drawback of this editor is its inability to execute lines of 
code whilst editing the function in which they occur. You can get round this by 


114 


trying out the line, putting quotes round it, assigning it into a character variable, 
opening Edit, and ‘Getting’ it, but this is a decidedly laborious process. One final 
feature is the use of the commands ‘X’, ‘Y’, and ‘Z’ to store any string of other 
commands. Typically you might want to change ‘DATA’ to ‘ADATA’ in half a 
dozen functions, in which case the command 


X R DATA ADATA 0/99, SAVE’ 
means you only have to type 
‘X, ANEXTFN’ 


do stack, and move Edit to ‘NEXTFN’ - to make each change. 
When you close Edit (Quit or FILE), it returns: 


‘EDIT CLOSED’ for Quit 
‘EDIT CLOSED: FUNCTION < FRED > FIXED’ for FILE 
This leads to code like 


NEW*CEDAMAT OLD;TEMP 


[1] aEDIT NUMERIC MATRIX 


[2] NEW<OLD 

C3] TEMP 6 O DFMT OLD 

C4] >(12=pA 'TEMP!)+0 

C5] NEW+(pOLD)*AMATEXEC TEMP 


for a distinctly quick and dirty (but quite effective) numeric edit. 

I am obviously not going to irritate you with 170 statements of terse and in- 
comprehensible code; however, just for interest, here are statements 90-99 which 
do the ‘MOVE’ command: 


C90] CMD<(~A\CMDe'MOVE ')/CMD 

C91] +((A/CMDeNUM,!/: ')xpCMD)+WHAT 

C92] CMDC(CMDe'/:')/ipCMD]<!' ! 

C93] CMD+¢Of (1+pAAF)L1+2p2CMD 

C94] F+aAAFCCMD¢CMD(1],CMD(1J+10f--/CMD;] 
C95] AAFe(~(11+pddF) e€CMD) £AAF 

C96] AAP«Of (1+1+pAAF)LAAP-(pCMD)xCMD[1]<AaAP 
C97] AAFe(~(1(1tpaaF )+1+pF) eAAP+i1tpF)XAAF 
C98] AAFCLAAP+i1+9F 3I1¢F 

[99] CONTINUE ,AAP+(1+pAAF)LAAP+149F 


AAF is the OCR of the function being edited; AAP is the current line pointer; CMD 
looks like ‘MO 2/5’, say; NUM is just ‘0123456789’. 

After lines 90-93, CMD has been validated, and interpreted to ‘2 5’. Line 94 
turns this into ‘2 3 4 5’, and takes a copy (called F) of these lines of AAF. Notice the 
implicit validation, which deals with 


M5 line 5 only 
or 
M7/3 line 7 only, rather than falling over! 
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Line 95 chops out the moved lines, and line 96 adjusts the pointer to compensate. 
Lines 97 and 98 open a suitable gap, and drop in the saved lines, and line 99 resets 
the pointer to the end of the moved chunk. It really is all easy stuff, just rather 
tedious, and you certainly ought to hire a tame idiot for a day or two to test it. 


‘A’ now falls over very rarely indeed, but I’m sure it could still be beaten by a really 
determined assailant with a sufficiently warped mind! 


Full-screen Panel Design and Editing 


You will remember from Chapter 9 that the screen is split into a number of fields 


(le ily Alle Gil A al A So ls i a 


WML 


LS GPAPDL AEA. DODD DL a E N E: 





which are defined by a six-column matrix, with one row for each field: 








Location Shape Att Int 
Field A 2 3 3 50 2 1 
Field B 6 2 10 5 2 2 
Field C 6 10 10 60 0 1 
Field D 24 2 1 78 2 1 





With only four fields to consider, we could just about get by with 
FSMAFMT 4 6p 2 5 3 50 2 1, ... etc. 


but for more complex screens some form of mechanization is obviously highly 
desirable. 

This mechanization seems to break down naturally into four phases (five if you 
want labelled fields) which are as follows: (a) defining the fields in the first place; 
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C1] 
C2] 


C3] 

C4] 

C5] 

[6] 

C7] 

C8] 

C9] 

C10] 
C11] 
[12] 
C13) 
C14] 
[15] 
C16] 
C17] 
[18] 
[19] 
[20] 
[21] 
[22] 
[23] 
[24] 
£25) 
[26] 
[27] 
[28] 
[29] 
C30] 
[31] 
C32] 


DRAW STK 


CANT 


NEW: 
OLD: 


PR: 
INT: 
TXT: 

CONT: 


SETTEXT: 


ST 


SKIP: 


; PANEL ; AFMT; ATEXT ; ACTION; POS 


AUSE FULL-SCREEN FACILITIES TO DRAW/AMEND PANELS, 
AAND SEE THE RESULTS BEFORE YOUR VERY EYES. 


+(1=0=140pPANEL+(71+POS+L/STKi! ,/')+STK¢,STK)+CANT 
+(NEW,CANT,OLD,CANT,CANT)[1+ONC PANEL] 
:20,e0+'NAME <<! ,(FPANEL),'>> IS NOT AVAILABLE! 
+CONT,pAFMT+ O 7 pO 

AFMT+(—~2+ 1 1 ,pAFMT) pAFMT+s PANEL 
+(PR,INT,7XT,CONT)([~3+1+pAFMT] 

AFMT+AFMT, 2 

AFMT+*AFMT, 1 

AFMT+AFMT,0O 

+(xONC PANEL,'ATEXT!)+SETTEXT 

+ST,pATEXT+! ! 

2'ATEXT¢!',PANEL,'ATEXT! 
sACTION€S5S | '1234'11+POS+STK 
:+(MEN,DR,CH,AT,7T,DONE,HP)[O 1 2 3 4 12 .ACTION] 
:>LKP,ACTION¢DRAWAMENU PANEL 

:>LKP ,ACTION<DRAWAINP 

:>LKP ,AACTION<DRAWACHK 

;°LKP ,AACTION<DRAWAATT 

:>9LKP ,AACTION<DRAWATXT 

;>LKP ,AACTION*<DRAWAHLP 

:>(xx/pAFMT)+SKIP 

M+ACTION¢'FIX NEW VERSION OF !,PANEL,' ? :- ! 
+(('YNt=1+(pACTION) +0) ,1)/FIX,SKIP,DONE 
:2PANEL,'¢AFMT'! 

‘PANEL FIXED! 

>(V/xAFMTC3:7)])+SKIP 

PANEL, 'ATEXT*ATEXT! 

'TEXT SAVED AS !,PANEL,'ATEXT' 

‘END OF PANEL DESIGN! 

FSMACLOSE 


Figure 10.1 





(b) checking the fields, and moving/extending/deleting them as necessary; (c) set- 
ting the attributes and intensities; (d) entering permanent text, such as headings, or 
underscore fillers for input fields. Each of these will occupy the whole screen, so 
there is no room for a command area, or any helpful messages. This places two 
constraints on the dialogue: 


è It must be entirely PF key driven. 


@ It must be almost childishly simple to use. 


With these in mind, I want first to look at the calling function, and then in detail 
at each of the four sub-sections; the code is a good illustration of the programming 
structures which I mentioned in Chapter 4. 
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Get panel name off stack 


What is ‘panel’ ?. 


iwalid — Not set Variable 





Error Set to How many columns ? 


Message 070 T7 
Add ptr. Add Int, ptr. | Add Att, 
int, ptr. 


Does text variable exist? 
Yes No 


Copy to ATEXT ATEXT «= ' ' 


Get first action off input stack 


Action ? 
O 1 2 3 4 Rest 


Input | Check | Att/int | Text bet 
quen 











Panel to be fixed ? 


No Yes 
Hold format 
Text defined ? 
No Yes 


Hold Text 


‘END OF PANEL DESIGN’ 


Figure 10.1 





We start with the main routine, called DRAW. See Figure 10.1 

This starts by checking for a valid format name, and picks up the associated text, 
if any. It then offers a menu of options (PF keys 1-4, PF12 to close, and anything 
else for ‘help’), and branches to the appropriate sub-section. Each of these is ter- 
minated by either ‘Enter’ -in which case it returns zero - or a PF key. By this 
means DRAW can be driven between any of the four phases (or to the exit) without 
returning to the menu in between. The design process is closed with PF key 12, and 
DRAW checks that you really do want to overwrite the old panel definition before 
it does so. If no permanent text has been defined, it doesn’t bother to save a text 
vector. 

So to the first phase of panel design proper: DRAWAINP (Figure 10.2). 

All that is achieved by lines 3-9 in Figure 10.2 is a pretty screen layout, on 
which row or column numbers are clearly marked: 
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ACTION¢DRAWA INP ; FRAME; LAB ;CT;FM;POS 


C1] AALLOW PANELS TO BE DRAWN/REDRAWN ON THE SCREEN. 
[2] FSMAFMT 1 1 24 79 0 

[3] FRAME+ 24 79 p!.! 

[4] FRAME[ 31+10x171<«'|! 

[5] FRAME[10 20 3;]<'-! 

C6] FRAME([5 10 15 20 314+10x17Je'+! 

[7] FRAME(1 2 314+10x17]+'1234567',[0.5] '1? 

C8) PRAME[L 312]¢(244+991)6 24 2 p 2 O F124 

C9] FRAME+¢,FRAME 

[10] +LAB+((1+pAFMT) pLOOP1 ) ,VRITE ,CT+1 

[11] LOOP1:+(OeAFMT[CT3;14])+*SKIP1 

C12] POS¢AFMT(CT; 1 2],(1.5] 1++/ 2 2 pAFMT(CT; ] 
C13] FRAME(1+ 24 79 1sPOS-1]«OAV([65+CT] 


C14] SKIP1:*LAB(CT«CT+1] 
C15] WRITE:1 FSMAW FRAME 


C16] ACTION¢FSMAPF 

C17) >(t 'aA,=FRAME¢,FSMAR 1)+*DONE 

C18) FM¢((+/V\O0AV(65+153]eFRAME) ,7)p0 

[19] >LAB+((1+pFM)pLOOP),EXIT,CT+1 

[20] ZLOOP:>(pPOS+(FRAME=DAV[65+CT])/11896)+SKIP2 
[21] POS<(0,0<-/POS[2;])¢POS+1+ 24 79 T 1+2pPOS 
[22] FM(CT; J<(4tPOS[£;1],1+--/POS), 2 1 0 

[23] *(CT>1+pAFMT)+SKIP2 

[24] +(QeAFMT(CT;14])+*SKIP2 

[25] FM(CT; 5 6 7J+AFMT(CT; 5 6 7] 


[26] SKIP2:+LAB(CT«CT+1 J 
[27] EXIT:AFMT+FM 
[28] DONE: 

y 


Figure 10.2 


ro n - DEAR A 


k ke Je ke Je ke k ke ke He ke ke k k k k k dek k k k kek kkk kk kkk kkk 


Lines 10-14 whip round drawing in any existing fields, by marking two corners 
with the letters A-Z, A, and A-Z (i.e. OAV [65+ ı 53] ). The screen is then held, 
the user’s action recorded, and the whole lot is read back in again. 


K ke e Ae k Je k Je Je ke ke de ke Je Je ke ke ke Je ke k de k k ke ke k ke ke k k k k k k 


MEN <erieetd o's Tirarem aa es ? AA E AE Sits 
CY a ee 7 ee eee ge Noe scntey etal iea 1 
k3 ib oe ped He % PEREP E alate | 
A E E RORE a tons le Buco s | 
EI aeee a E E E See De E ee + 
EG: ive Gea poneren ) E eee | 
BOT sk aay au iets inanimate tine Ugh actrees B | 
Ss E E E PE ee EEE | 
CE aeea an er EATE EEE | 
*10-------- +--------- +--------- +-- 
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Set Format; clear FRAME 
fields remaining 


Active field ? 
Yes 


Mark; top left; bottom right 


Write: hold; read screen back into FRAME 
FRAME totally blank ? 
Yes No 


Clear new format 


fields remaining 















Marking character(s) found ? 


Yes 
Set row of format 


New field ? 

No 
R back old Att,Int, 
¥ ptr. into format row 

Overwrite old format 


Figure 10.2 


Each pair of letters defines a field (a single letter is treated as a pair in the same 
place), and is turned into a row in the new format matrix by lines 21 and 22. If the 
field existed already, then its old attribute, intensity, and text pointer are copied 
back (line 25), otherwise the field is given the default of output/normal/no text. 
Suppose we marked the ‘PF 1’ screen with a couple of ‘As’, then pressed PF2: 











k k k Je k Je k de k ke ke ke k ke k k k ke k ke k k k k ke k k k ke k k k k k k 


* 
k 
* 
x <AAAAAAAAAAAAAAA 
x <AAAAAAAAAAAAAAA 
* <AAAAAAAAAAAAAAA 
* 
* 
* 
* 


This is the second phase of screen-design, in which fields may be moved, extended, 
or deleted. It also shows any overlapping fields with dominoes in the area of over- 
lap, and indicates obscured areas with quads: 


120 


ACTION+DRAWACHK ; FRAME ;LAB;CT;ROW;COL ;MULT ;CH 


EEJ 


[2] 
C3] 
C4] 


[5] LOOP: 


C6] 
C7] 
[8] 
[9] 
C10] 


C11] SKIP: 
C12] VR: 


[13] 
C14) 
C15] 
[16] LpP2 
C17] 
C18] 
C19] 
[20] 
[21] 
[22] 
[23] 
[24] 


[25] DEL: 
[26] UND: 


ACHECK CURRENT FMT: UPDATES AFMT FROM ROOT FN. 


FSMAFMT 1 1 24 790 

FRAME+ 24 79 p65 

>+LAB+((1+tpAFMT)pLOOP) ,WR,CT+1 
>+(OeAFMT(CT:14])+SKIP 

ROWe 1+AFMT(CT;1J+:10fAFMT(CT;3] 

COL¢ 1+AFMT(CT;2]+10f AFMT(CT; 4] 
FRAME(ROW;COLJ«(179,CT+65)(1+FRAME[ROW;COL]=65] 
+(COL¢ 1+14COL)+SKIP 

FRAME[LROW:COL]+ 159 188[(1+FRAME[LROW;COL]>65] 
>LABCCT¢CT+1 J 

1 FSMAW DAVE FRAME] 

ACTION¢FSMAPF 

FRAME¢FSMAR 1 

>LAB<((1t+tpAFMT) pLP2) ,DONE ,CT+1 
:>(OeAFMT(CT;14])+UND 

ROW<«24{ 1+AFMT(CT;311+10f AFMT(CT;3] 

COL¢79L 1+AFMT(CT;2J]+:1 Of AFMT(CT; 4] 
CH+,FRAME[ROW;COL] 

+(CT DRAWACHAEXT CH)+*DEL 
>((pCH)<L/CHi '++¢3!' )+DEL 
MULT+101L/'!1234567891'1CH 
AFMT(CT;2]+¢(80-AFMT(CT;4])L1[AFMT(CT;2]+MULTx-/'>«' «CH 
AFMT(CT;1]+(25-AFMT(CT;3])L1PAFMTCCT;1]+MULTx-/'++' «CH 
AFMT(CT; ]©AFMT(CT; ]x~'V'teCH 

+LAB(CT¢CT+1 J 


[27] DONE: 


y 


RC+CT 


C1] 
[2] 
C3] 


C4] 
C5] 
[oJ 
C7] 
C8] 
C9) 
C10] 


C11] 


[12] 
[13] 
C14] 
C15] 
C16] 


DRAWACHAEXT CH;OLD;MULT;TAB; TEXT 

eEXTEND (OR CHOP) FIELD IN ANY DIRECTION. 

a<<CH>> IS THE RAVELLED CHARACTERS FROM FIELD <<CT>> 
aUPDATES AFMT AND ATEXT FROM ROOT FN 


>(v/t-+'eCH)+RC<0 

TABe 4 49° 101000100 1010001 
MULT<(~1*'-'eCH)x10/L/'1234567890'1CH 

OLD+AFMT(CT; 3 4] 

AFMT[CT; 14] ¢AFMTCCT;14]+MULTXTABL4LL/'++¢>'1CH; J 
AFMT[CT;14]+ 1 1 0 O fF 24 79 24 79 LAFMT[CT;14] 
AFMT[CT;14]+((25 80 -AFMT[CT; 3 4J), 24 79)LAFMT[CT; 14) 


APAD TEXT (IF ANY) AS REQUIRED 


+AFMT(CT;7]4DONE 

TEXT+ATEXT[ POS ( pATEXT) LAFMTLCT; 7]+1x/OLD] 
AFMT[ 37]*¢AFMTC 37J-(x/OLD)xAFMT( 37 J2AFMT[CT;7] 
AFMT(CT37 ]+pATEXT¢(~(1 pATEXT) €POS) /ATEXT 
ATEXTCATEXT,,(AFMT[CT; 3 4])tOLDpTEXT 


[17] DONE:RC+1 


Vv 


Figure 10.3 





Je Je ke ke ke k ke k 


+ + Fe e, FF E, FF 


k ke k ke ke de ke ke ke ke ke k ke ke ke ke Je k Fe de de ke k Je de k k 


<AAAAAAAAAAAAAAA 

<AAAAAAAAAAATISEEBBBBB 

< AAAAAAAAAAADEREBBBBB 
<BBBBBBBB 
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Set format; clear FRAME 
any fields remaining 
Field active? 
Yes 
Fill with ‘A'-'Z'; B where overlapped 
Room to show attribute chars ? 


No Ye 
wa Indicate with '<° or 'D' if obscured 


Write; hold; read screen back into FRAME 


any fields remaining 


Field active ? 
No Yes 


Extract chars from field 


Were any extensions done ? 
Yes No 
Any arrows present? 
No Yes 


Set multiplier 


Move rows; columns 


Is ‘v' present? 
Yes 


Cancel field 


Do '+' or '-' occur in field ? 
No Yes 
Return O Set: lookup table, multiplier; +- 


Store old format 
li Extend: rows; columns 












Cut down to fit on screen 
Any text held ? 
No Yes 


Extract old text; adjust ptrs. 


Pad text; replace in ATEXT 
Set new ptr. 


Figure 10.3 





Thus making potential disasters pretty obvious! This is handled by statements 2-12 
of DRAWACHK (Figure 10.3), which incidentally breaks one of my rules (Chapter 
5) by indexing DAV explicitly to get ‘GO<’. 

Having set up the screen, it holds it, reads it back, and takes each field in turn to 
check for possible changes. The sort of thing it accepts is: 
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ACTION¢DRAWAATT; ROW ;COL;LAB;CT;FRAME ;CH 





[1] aSET FIELD ATTRIBUTES AND INTENSITIES. 
[2] aUPDATES COLS 5 AND 6 OF AFMT FROM ROOT FN. 
[3] FSMAFMT 1 1 24 79 0 
C4] FRAME+ 24 79 pt ! 
[5] +LAB+((1+pAFMT)pLOOP1) ,DISP,CT+1 
[6] LOOP1:+(OeAFMT(CT;14])+SKIP 
[7] ROW+ 1+AFMT(CT;1]+1 OF AFMT(CT; 3] 
[8] COL¢ 1+AFMT(CT;2]+1 0 AFMT(CT; 4] 
C9] FRAME[LROW;COLJ+'t+! 
[10] COL+78LCOL 
C11] FRAME([ROW(1];COL(1J]]+'I0'(1f2L1+4FMTCCT;5]] 
(12) FRAME[ROW([1]3;1+COL(1J]«'ZNH'C13L1+A4FMTCCT;6]] 
[13] SKIP:*LAB(CT+CT+1 ] 
[14] DISP:1 FSMAW FRAME 
[15] ACTION+F SMA PF 
[16] >(' ta,=,FRAME¢FSMAR 1)+DONE 
C17] +LAB+((1+*pAFMT) pLOOP2) ,DONE ,CT+1 
[18] LOOP2:+(OeAFMT(CT;14])*SKIP2 
[19] CH+FRAME(AFMT(CT;1]; 0 1 +78LAFMT(CT;2]] 
[20] AFMT[CT;5]#14(('OI'eCH)/ 2 0),2 
[21] AFMT[CT;6]<14+(('ZNH'eCH)/ 0 1 2),1 
[22] SKIP2 : *LABLCT¢CT+1 1] 
[23] DONE: 

y 

Figure 10.4 

> move field one place right 
45 move field five places up 


+24 add two rows to bottom of field 


-3 remove three right-most columns of field 


y delete 


field altogether 


All of these may be typed anywhere in the field, e.g. the screen shown as 


k k k k k k kk k k 


* * FF FF FF FE 


k k k k k ke ke de k k k k de k ke ke ke k ke k k k k k 


will move field A down two rows. Again, most of the validation is implicit, such as 
the check on lines 21 and 22 to make sure you don’t move any fields clean off the 


screen! 


Field extension is handled by a separate function, DRAWACHAEXT, which is 
called once for every screen field checked. Line 2 sends it straight out if it can’t 





Set format; clear FRAME 


any fields remaining 


Field active ? 
No Yes 


Fill whole field with '+' 


Attri ? 
Output ttribute ‘ input 
Set top left to 'O' Set top left to ‘I' 


Intensity ? 
Zero Normal Highlighted 


Set next char to'Z' | Set to 'N' Set to 'H' 
Write; hold; read screen back into FRAME 


FRAME totally blank ? 
No 
any fields remaining 


Field active ? 
No Yes 
Extract 2 chars at top left 
Set Attribute (default output) 


Set Intensity (default normal) 


Figure 10.4 



















Yes 
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find a ‘+’ or a “~, otherwise it checks for ‘above or below’, and decides how many 
extra rows/columns are needed (the default is one column to the right). Having 
amended the format matrix, it proceeds to pad (or chop) any fixed text to match. 
Finally it returns 1 to stop ‘move’ getting confused by all those arrows! 

Setting attributes and intensities is by far the most straightforward section of 
panel design, and the structure of ‘DRAWAATT?’ is very similar to the two func- 
tions we have just seen (see Figure 10.4). 

Possible attributes are ʻO’ for output and ‘I’ for input; possible intensities are 
‘Z’ for zero (hidden), ‘N’ for normal, and ‘H’ for highlighted. The defaults are set 
when the fields are first defined, and such a field would look like 


k k kkk k k k k k k k k k k k ke k k k k k k k ke ke k k ke k ke k k k 


ee E E E E 


+ 


ON++t+¢tttttette+ 
FHEHTHT HE THEE +E H+ 
+tttt++tt+++++++ 


It could then be changed (e.g. to input highlighted) by overtyping the top left-hand 
corner with the appropriate letters (‘IH’ in this case). 
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ACTION¢DRAWATXT ; FRAME ;LAB;CT ;ROW;COL;CH;POS 


C1) AHOLD FIXED TEXT AGAINST PANEL DEFINITION 
C2) AUPDATES AFMT AND ATEXT FROM ROOT FUNCTION. 
[3] FSMAFMT 1 1 24 79 0 
C4] FRAME+ 24 79 p! ! 
C5] +LAB+((1+*pAFMT)pLOOP) ,EXIT,CT+1 
[6] LOOP: +(OcAFMT(CT;14])+SKIP 
C7] ROW 14+AFMT(CT;1]+1.0f AFMT(CT;3] 
[8] COL 1+AFMT(CT;2]+10f AFMT[CT; 4] 
C9] +(POS«AFMT(CT;7])+UNDEF 
(10) CH+ATEXT[ (pATEXT)L,POS+1x/AFMT[CT; 3 4J] 
C11] FRAME[ROW;COLJ+AFMT(CT; 3 4] CH 
C12] +SKIP 
[13]  UNDEF:FRAME[LROW;COLJ¢'1°'(1+xAFMT(CT;5]] 
C14) SKIP: *LAB(CT¢CT+1 ] 
C15] EXIT:1 FSMAW FRAME 
[16] ACTION¢FSMAPF 
C17) +(' t,=,FRAME¢FSMAR 1)+DONE 
[18] ATEXTe{1p'!' ! 
[19] AFMT[ ;7 J40 
[20] >LAB+((1+pAFMT) pLOOP2) ,DONE ,CT+1 
[21] LOOP2:+(OcAFMT(CT;14])+SKIP2 
[22] ROW- 1+AFMT(CT;1]+10f AFMT(CT; 3] 
[23] COL¢ 1+AFMT(CT;2]+10fF AFMT(CT; 4] 
C24] CH« ,FRAME[ROW;COL J 
[25] +(SKIP2 ,SCAL ,HOLDTXT)(1+(~'V'eCH)x2L+/~CHe'1°'] 
[26] SCAL :CH¢(pCH)p(~CHe'1°!')/CH 
[27] HOLDTXT:CH[ (CHetic!)/i1pCH]+! ! 
[28] AFMTCCT;7J]-pATEXT 
[29] ATEXT¢*ATEXT ,CH 
[30] SKIP2 :*LAB(CT*CT+1 ] 
C31] DONE: 
y 


Figure 10.5 





That leaves only the fixing of text into permanent fields, such as headings and 
‘help’ messages (Figure 10.5). Any fields as yet without text are filled up with iotas 
and jots for input and output fields respectively ; otherwise the previously entered 
text is displayed. The text is then reassigned field by field (lines 19-28), the one 
refinement being that if only one character is entered in a field, it is replicated to 


fill the entire field: 
kkk kk kk kkk kkk kk kk kkk kk k k k k kek k k k k k k kkk k k k k 
* * 
* * 
k oeo00000000 * 
x ceAcTITLEo 9 00 <<< Ses >> x» A TITLE 
* o0o0000000ọỌ oooo * 
* * ae 


A ‘V’ anywhere 


in a field will cancel all the text previously entered for that field, 


and an additional possibility (not shown here) would be to allow the text for any 
field to be edited as if it were a character matrix, i.e. to call the full-screen editor 
from within ‘DRAW’. 
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Set format; clear FRAME 


any fields remaining 


Field active ? 
No Yes 
Extract: row; column 
Text held against field ? 
Yes No 

Field attribute ? 
Copy text Output Input 
into FRAME| Fill field with 'o' | Fill field with '? 


Write; hold; read screen back into FRAME 


FRAME totally blank ? 
Yes No 
Set up new text string; pointers 


fields remaining 


Field active ? 
No Yes 
Extract chars from FRAME 


Check for chars other than ‘co 
'y' _ None On 























Many 


e 
Replicate it kA 
Blank out 'ue' 


Move into ATEXT; set ptr. 





Figure 10.5 





That is all I want to say on the subject of high-level panel design. Used in con- 
junction with the FSM functions of Chapter 9 it is a remarkably flexible and power- 
ful tool; what’s more it really is fun to use! Being able to type 3° or ‘t4’ into a 
succession of fields, press PF2, and watch them leap to their appointed places is a 
positively exhilarating experience. I hope you find this too, but even if you don’t 
use my panel-design method as it stands, then I trust that these examples of 
properly structured, clearly coded APL will still help when you come to write 
similar software yourself. 


Automatic Documentation 


This must be the dream of anyone who has ever programmed a computer! Well, in 
Chapter 7 I said it was possible, so I had better set about proving it. The twin aims 
of any system documentation are (a) to make ‘fire-fighting’ as simple as possible; 
(b) to allow easy change in the future - not necessarily by the system author. 
Armed only with ONL and OCR, the determined APL programmer can go a long 
way towards satisfying these needs, but for once it isn’t a particularly easy task. In 
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fact it is very much the reverse case to the full-screen editor; here it is very easy to 
define what you want, and decidedly tricky to program it efficiently. 

First the easy bit: somewhere on the system there should be made available a 
group of functions (probably called DOCGP), which can be copied into any work- 
space, and set running by the command ‘DOCUMENT’. They should produce (pre- 
ferably on a high-speed printer) the following: 


@ date and time (on every page) 
@ a copy of ‘DESCRIBP’, be it function or variable 


© copies of any ‘HOWXXX’ functions or variables which occur in the workspace 


è an alphabetical contents list, showing function name; number of statements; 
calling syntax; leading comment lines 


© some form of tree-structure, showing the relationships between called and 
calling functions 


è listings of all the (unlocked!) functions in the workspace (except itself), with 
notes on what calls each; what each calls; which global variables each refer- 
ences 


© a pictorial representation of all the full-screen panels, showing the text held 
against each 


@ an alphabetical list of all global variables, showing type; shape; where 
referenced 


The problem lies in how one sets about producing these for a reasonably large 
workspace, without chewing up a quite absurd amount of CPU. The best I can offer 
is between 20 and 50s of CPU time (IBM 3032) to run a full documentation on what 
I consider to be a reasonably big workspace (1000-2000 statements; upwards of 
100 functions). I know this sounds a lot, but set against the time taken to compile a 
500-statement PL/1 program (typically 40-50 s) it isn’t really too terrible. If you 
can find some way of running your DOCUMENTs overnight in batch, then so much 
the better; if not there are still some 400 min in the working day, and you have as 
much right to one of these as your PL/1 colleagues! 

The overall structure of ‘DOCUMENT?’ looks rather like this: 
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DESCR ——» printed ‘DESCRIBE’ 


HOW ——> all 'HOWXXX' functions 


——> contents list 
FUNCTION CONTENTS 
X- REF 
STRUC workspace tree 
VARIABLE 
X- REF 










LIST ——>_ annotated function listings 


el 
| 


PANELS ——>_ full-screen panels 


GLOBALS 


The first subject I want to consider in detail is the creation of those function and 
variable cross-reference tables. Once these exist, the rest of the job is relatively plain 
sailing, although the structure analysis is worth a paragraph or two - if only as an 
interesting example of the use of recursion! The object is to end up with a two- 
column matrix of indices into the tables of names, the first column being the calling 
function, the second the function it calls: 


——>___ global-variable details 





ROOT 


ROOT 
ROOTAFN2 







ROOTAFN2 





Calling Called 


- and similarly for functions and referenced variables. 
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Clearly we must take the OCR of each function in turn, and having printed its 
details on the contents list we must then check it for any functions which it men- 
tions, or any variables it refers to. The way not to do this is to take each other 
function name in turn, and perform a string-search for that name. For one thing 
this tells you far more than you really need to know, and in a well structured work- 
space with lots of small functions you have just created a nested loop of CPU- 
gobbling proportions. A far better, but somewhat more subtle approach is to cut 
down your function to a table of the names which might be global. It then only 
takes a single ‘A.=’ against the lists of functions and variables to sieve out those 
names which need to be appended to each of your tables. Here is the code to 
reduce any function to such a list of names: it is worth quoting if only as a quite 
remarkable selection of the more obscure idioms from Chapter 8! 


OCC+ASTRIP FN;HEADER ;ALPH 


[1] aCHOP FN DOWN TO LIST OF NON-LOCALISED NAMES. 


C2] ALPH¢'1234567890! ,OAV(65+154) 
[3]  FN+¢OCR FN 


[4] aFIRST SET UP HEADER AS CHECKLIST. 


C5] HEADER¢! ;+e' ATAB FN(13] 
[6] FNe 1 O 4+FN 


[7] aCHOP OUT COMMENT LINES, AND RAVEL: 

C8] FN¢,((~FNV.='at)f#FN),' ! 

[9] ATHEN SCRAP ANYTHING WITHIN QUOTES: 

[10] FN«(~(FN=t'! t)ve4\FN=tt tt) /FN 

[11] aSUBSTITUTE BLANK FOR NON-ALPH AND CHOP MULT BLANKS: 


[12] FNCU(~FNeALPH)/ipFN]<«' ! 
[13] FNe(~(' '=FN)At '=1OFN)/FN 


[14] ASET UP REMAINING NAMES AS TABLE: 

C15] FN<«'t ' ATAB FN 

[16] aCHOP OUT ROWS WHICH ARE ALL NUMERIC: 

[17] FN¢e(~A/FNe' 0123456789! )#FN 

[18] AREMOVE NAMES REFERENCED IN HEADER: 

C19] FN+¢(~v/FNA.=&((14+pHEADER) ,14+eFN) +HEADER) /FN 
[20] aFINALLY TAKE OUT DUPLICATES: 


[21] occe(1 1 &<\FNA.=aFN)/FN 
Vv 
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You may recall from Chapter 4 that there are two main criteria which determine 
whether a problem should be defined recursively: (a) it should decompose into sub- 
problems which are either trivial, or break down in the same way as the main prob- 
lem; (b) at some stage it must back-track either to the main problem, or to a 
previous sub-problem. 

The task of drawing out a structure-tree from the function cross-reference table 
is just such a problem, and illustrates the use of recursion very well. 


ROOT... 
: ROOTAFN1 
: ROOTAFN2... 
:UTILI 
:UTIL2 
: ROOTAFN3 
sey ete. 


Here the main problem is to draw the structure of ROOT. The first sub-problem (to 
draw ROOTAFN1) is trivial; the second is to draw ROOTAFN2. This goes down 
one level further to two trivial sub-sub-problems, and then back-tracks to attack 
ROOTAEFN3 and so on. Figure 10.6 illustrates the functions to do it. 
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NAMELIST ASTRUC XREF;LEN;ROOTS; PAGE ;NEST 


C1] ADRAW OUT WS STRUCTURE AS TREE 
(2) a NAMELIST IS A CHARACTER TABLE OF FN NAMES. 
C3] a XREF IS A TWO-COLUMN MATRIX OF CLNG/CLD PTRS. 
ca] ATAKE SIMPLEST ROOTS FIRST 
c5] ROOTS+¢(~(114pNAMELIST) eXREF[ 32])/11+pNAMELIST 
C6] ROOTS+ROOTS[ A+/ROOTS? . =XREF[ 31]] 
C7] aRUN THROUGH EACH ROOT IN TURN 
[8] ROOTS+0 ,ROOTS 
[9] LOOP:+(pROOTS<1+ROOTS)+DONE 
[10] NEST+PAGE+10 
C11] O ATREE ROOTS[1] 
C12] aDISPLAY COMPLETED PAGE, SUITABLY INDENTED 
C13] LEN+1 0f 2+1+pNAMELIST 
C14] O 1 +(-LENxNEST)$((pNEST) ,80)+':',NAMELIST[ PAGE; ] 
r15J +LOOP 
[16] DONE:'WS STRUCTURE ANALYSIS COMPLETE! 
y i 


LEVEL ATREE FROM;TO 


C1] ARECURSIVE TREE SEARCH ... 
[2] AUPDATES <<NEST>> AND <<PAGE>> FROM ASTRUC, 
C3] >(pTO+(FROM=XREF[ ;1])/XREF[;2])+MORE 
C4) aWE SEEM TO HAVE REACHED A LEAF. 
C5] PAGE+¢PAGE , FROM 
C6] NEST¢NEST ,LEVEL 
[7] >EXIT 
C8) aSORT BRANCH BY INCREASING COMPLEXITY... 
[9] MORE: TO«TO[A+/TOo .=XREF[31]] 
(10) PAGE¢PAGE , FROM 
C11] NEST¢NEST , LEVEL 
[12] AAND EXPLORE TWIGS. 
[13] LOOP: (LEVEL+1) ATREE TO[1] 
C14) +(pTO+1+TO)*LOOP 
[15] EXIT: 
y 
Figure 10.6 





The rest of workspace documentation falls firmly into the category of ‘straight- 
forward but tedious’ so I shan’t discuss any more of it in detail. Suffice it to say that 
you will find the effort involved in writing the necessary functions repaid many 
times over. 

In this chapter I have referred several times to ‘efficient code’, because it is in 
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Sort Roots by size of Tree 


Roots left 


Clear Page and Nesting level 


Explore 


indent and display Page 
'WS STRUCTURE ANALYSIS COMPLETE’ 


Has Branch any Twigs ? 
No Yes 


Add Branch Sort by complexity of Twigs 


to Page 
Add Branch to Page 


Figure 10.6 
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Next 
Twig 


no Twigs left 








system utilities that efficiency matters most. I now want to broaden that view by 
considering in more detail just how APL works, and how you can make the best use 
of those precious CPU seconds. 


Chapter 11 
Efficiency in APL 


One of the recurring themes in this book has been that you - the programmer - are 
a more expensive and valuable resource to your company than is its computer. In 
this chapter I want to put this consideration temporarily into abeyance, and to look 
at some ways and means of making your APL code go faster. When trying to code 
efficient APL you have a twofold problem to face: your code must drive the inter- 
preter; and its code must drive the CPU. Very often the twin objectives (efficient 
interpretation and efficient execution) are incompatible, and it is rarely clear where 
the best balance lies between them. In order to shed some light on the problem I 
am first going to discuss the way APL is interpreted, and what really happens when 
a function executes. Then I want to give you a feel for the ‘interpretation versus 
execution’ problem by quoting a selection of timed examples. Finally I shall round 
off with a list of ‘good habits’ to get into if you want to speed up your APL code. 

If you were sitting down to write an APL interpreter, which part of it would 
you expect to give you most trouble? Would it be the code for the obscure and 
strange functions, like transpose and encode? Would it be sorting out the order of 
execution in a complex line of code, full of brackets and indexing? In fact it is 
neither: the single toughest nut the interpreter has to crack is exemplified by the 
innocent-looking 


Ae3 47112 


The problem is that the next statement could equally well be 


A+500 50p'RABBITS ! 


and the next 


A¢i0 


No conventional computer language gives a programmer this kind of freedom, and 
APL pays dearly for its flexibility. In a language such as PL/1, you would say 


DECLARE A CHARACTER (20); 


somewhere towards the start of the program. The compiler would take in turn all 
such ‘DECLARE’ statements, and would allocate a suitable chunk of storage for 
each object you had named. There those objects would remain until the program 
came to an end, and any references to them would be treated simply as requests to 
fetch from (or write to) the appropriate area of storage. 
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APL cannot do this, because it cannot assume that it will always need the same 
amount of storage for an object just because it happens to have the same name. 
Consequently it cannot simply replace a name by its location; it must maintain a 
constantly updated register of names, together with the most recent address of 
each. As names are used and re-used, the objects to which they refer will migrate 
around the available workspace, constantly re-occupying old slots as these become 
vacant. Exactly how interpreters find the available spaces is a subject well beyond 
the scope of this book, for one thing there are nearly as many different ways of 
doing it as there are interpreters! How they remember where an object is - and 
what it looks like - is the subject I want to move to next. 

To return to the example a page or so back; you log on to the system, get a 
clear APL workspace, and type 


At3 49112 


By doing so, you have created an object with a given data type (numeric), rank 
(2), and shape (3,4); you have established that the symbol ‘A’ refers to a variable: 
and you have ensured that any future reference to that symbol will recover from 
memory the matrix you assigned to it. To deal with all this, APL needs two things: 


© The SYMBOL TABLE tells it which names are currently defined, whether 
they refer to functions or variables, and where the objects in question are 
currently hiding. 


@ A DATA DESCRIPTOR is attached to each and every variable, and tells 
APL all it needs to know about the nature of that variable. 


In the case of the example just described, if we subsequently type 
FRED+20p'ABC ! 


then the symbol table and workspace will look rather like 


ili Steet 23456 7 


7 


SYMBOL TABLE 


a “Descriptor ~” Data 


(c[1] 20 | ABC ABCA.......... 





Not all interpreters, incidentally, hold the descriptors with the data in this way. 
Although they give themselves yet another pointer (from the descriptor to the data 
itself) to hold, they do gain considerably on operations like ravel and transpose, 
because these can be done without touching the actual data at all. 
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To see why this dynamic data management can be so costly, let’s look at a simple 
program line as it would be tackled by APL and by PL/1: 


APL PL/1 

I+I+1 I=I+1; 

Look up ‘T in the symbol Fetch (address of I) value. 
table. Fetch it from that Increment it. 

address; check its data Store (address of I) result. 


type, shape. Add 1 to it. 
Find some free memory. 
Put the result there. 

Set the symbol table entry 
for ‘I’ to that address. 


The PL/1 version is essentially three assembler instructions; I don’t know how 
many the APL version is, but it is obviously many, many more than that. To appreci- 
ate just what a killer this storage management can be, here are two apparently 
equivalent ways of approaching a common programming task. The object of the | 
exercise is to read up to 1000 records (each of 80 bytes) from a file, and to store 
them in a character matrix. The two approaches are 


Method 1 Method 2 
M+0 80p! ! M<1000 80p! ! 
[ee ] INPUT M(CT; J<INPUT 


M¢((CT-1) ,80)4M 


The point about Method 1 is that every time a record is read, all the previous input 
is moved to a new area of store. Consequently its CPU consumption is roughly 
proportional to the square of the number of records read in; Method 2 only moves 
‘M’ once - right at the end - and its CPU use only goes up linearly. I hope Figure 
11.1 leaves you suitably terrified - it certainly shocked me when I first drew it! 

Having sorted out its storage problems, the next thing the interpreter must do is 
to disentangle your code into commands which it can execute. For the straight- 
forward arithmetic functions this is simple enough, and the time taken to execute 
them varies as much as one might expect (Table 11.1) from the intrinsic ‘hardness’ 
of each. 

When we move into the realms of the more complex ‘data management’ functions, 
then a good rule of thumb is that the less general the function, the quicker it will 
tend to go. This is nicely illustrated by the three data-selection processes following: 


è ‘Take’ is the simplest of the three. It is limited to abstracting a contiguous 
block of data from one corner of a target array. 


@ ‘Compression’ can select rows (or columns) from anywhere in the body of a 
table, but only in the order in which they originally occurred. It is also limited 
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Execution time (s) 





Method 1 
3 
2 
{ 
Method 2 
O 500 1000 Records 
Figure 11.1 Execution time versus number of input records. Timings are given in 
3032 CPU seconds 
Table 11.1 
Time with A+?1000p10 
Function A fn B B+?1000p10 
+ fF L = 2 ms 
- | 4 ms 
x 5 ms 
Łe 15 ms 
i 29 ms 
+/AXxA 11 ms 
+/Ax2 12 ms 


(assuming your system doesn’t have ‘replicate’) to taking each selected row 
once only. 


@ ‘Indexing’ can take as many copies as you want of any row, in any order 
whatsoever. 


It is not too surprising to find that of the three ‘take’ is about twice as fast as 
‘compress’, which is about twice as fast as ‘indexing’: 
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M+100 500p? 'RABBITS ! 


M1+M[133] 1.4 ms 
M1+<((140M)431)/M 0.69 ms 
M1+¢(3,1+9M) 4M 0.29 ms 


All three expressions will select the top three rows of a table, but the generality of 
‘compress’ and ‘indexing’ is not required to do this. For clarity, however, there is 
no denying that the version using ‘indexing’ is by far the best of the three, and it is 
the one I would normally use. 

So much for APL in its desk-calculator mode; when you execute a defined 
function then several further things happen, all of which have some bearing on 
efficiency. As an example, consider the following sequence of operations: 


RA PLUS B define a function called ‘PLUS’ 
[1] RAB | 
Vv 
A¢'CAT?! store ‘A’ 
P+6 store ‘P’ 
5 PLUS P execute ‘PLUS’ 
11 result is displayed 


When you have defined ‘PLUS’, ‘A’, and ‘P’, the workspace will look like this: 








@ Because it uses ‘A’ to represent one argument, PLUS will need a symbol- 
table entry for it. To preserve the original value of ‘A’ (i.e. ‘CAT’) the old 


As soon as ‘PLUS’ is invoked, several things happen: 
pointer is saved on the STACK. | 
| 
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@ At the same time, ‘B’ is put on the symbol table, with a pointer to the same 
place as ‘P’. 


@ A work area is then set up, containing the value 5, and pointed to by ‘A’. 


STACK 





R-A PLUS B 
i R-A+B 


Execution now proceeds, resulting in a further entry ‘R? in the symbol table, 
pointing to an object with a value of 11. Notice that if you had at any stage modi- 
fied ‘B’ inside the function, it would have been forced to take an extra copy, 
otherwise it would also have changed ‘P’! 

Finally the whole process unwinds: 


@ The pointer to ‘A’ is restored from the stack. 
@ The pointer to ‘B’ is cleared (but the entry does stay on the symbol table). 
@ The result is returned (and printed) and the pointer to ‘R’ is also cleared. 


I never knew life was so complicated: imagine what happens at the bottom of a 
tree of 10 function calls! On second thoughts, don’t - one neurotic APL pro- 
grammer is enough!! 

One way of measuring the overhead of function call is to take a recursively 
defined function, and expand it into a simple repetitive form: 


SERIES+¢SOFAR FIB N recursive 
[1] >(N=p,SERIES+SOFAR)+0 
[2] SERIES¢(SOFAR,+/ 2+SOFAR) FIB N 

v 


SERIES+FIB1 N repetitive 
[1] SERIES<,1 
C2] >(N=pSERIES)+0 
[3] SERIES+SERIES,+/ 2+*SERIES 
[4] + (N=pSERIES)+t0 
[5] SERIES+SERIES,+/ 2+SERIES 
CO} aneia etc. 


Figure 11.2 compares the execution times of the two versions for a variety of 
values of N. Two points to note are as follows: 
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CPU ms 





O 20 40 60 


No. of terms 
Figure 11.2 


@ The discontinuity at N = 47 is caused by the switch to floating-point arithmetic. 


@ The overhead is actually quite surprisingly low; not more than 0.2 ms per 
function call at the most. 


Incidentally, an iterative version of FIB1 executes in very much the same times as 
its repetitive counterpart. | 

You will remember from Chapter 4 that any program can be structured into one 
of the following: sequential; alternative; iterative. In APL the beauty of the altern- 
ative structure is that only the path which is taken needs to be interpreted. On the 
other hand, the code in an iterative structure will be interpreted every time the 
algorithm loops around. Moral: branches are fine as long as they are used to select 
from a range of options, not to iterate over the same piece of code again and again. 
For example, to display “TRUE’ or ‘FALSE’ depending on the result of a test, we 
could use 


(w\2pTEST)/'TRUE ',[0.5] 'FALSE! 1.15 ms 
or 
+TEST+SKIP 1.08 ms 
'TRUE! 
+END 


SKIP: 'FALSE! 
END: 'READY' 


I agree that the non-branching form is often clearer, but it may be marginally 
slower, as in the case above. The same applies to the use of ‘execute’ to avoid 
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branching: here I personally would almost always opt for the branch as being the 
more efficient of the two. 

Of course even when the interpreter has finished with your code, the resulting 
assembler still has to be executed, and it is almost impossible to separate the time 
taken by each phase. What you can do is to compare some alternative ways of 
achieving the same result, and to try and get some feel for the balance between 
interpretation and execution. Consider the following two ways of generating prime 
numbers from 1 to N: 


PRIMES¢PR N 


C1] PRIMES<(2=+/0=(iN)°.]iN)/iN 
y 


PPERATOS N;LAST;D 


C1] APRIME NUMBERS BY THE SIEVE OF ERATOSTHENES 
[2] PP<+1+.1N-1 
[3] LAST¢Nx'+D¢2 
[4] MASK:>(LAST<D)+0 
[5] PP+((D=PP)vO#D|PP)/PP 
C6] D¢+PP[1+PPiD] 
C7) ~MASK 
[8] AORIGINAL FROM APL\360 PRIMER 
C9] APAGE 160 
y 


The algorithm using ‘the mask of Eratosthenes’ progressively masks out large 
numbers of potential primes at each iteration; consequently it does far fewer 
comparisons and residues in all. The difference between them is really quite dram- 
atic - see Table 11.2. 


Table 11.2 
N PR ERATOS 
10 3 4 
50 24 7 
100 94 11 
200 358 15 
500 WS FULL 33 
1000 WS FULL 62 


In fact, out of curiosity, I coded a version of ERATOS in PL/1 and the result 
was quite interesting (Figure 11.3). Which line do you think represents the APL, 
and which the compiled PL/1? In fact the APL is the lower line of the two; it 
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1.2 


0.8 
0.6 
0.4 


0.2 


O 2000 4000 6000 8000 10000 
Primes up to 


Figure 11.3 


consistently uses some 200 ms less than the PL/1 equivalent! I leave you to draw 
your own conclusions. 

This policy of progressively reducing data by successive iterations pays dividends 
in many other areas. String-searching is one I’ve already mentioned (ASS in Chapter 
8), but a more general use might be in the selection of data based on a series of 
conditions: 


PERSONNEL WHERE (AGE>35) AND SALARY<5000 


Rather than creating complete masks for each condition, ‘anding’ them, then com- 
pressing, it might well be better to take a step-by step approach: 


WORK¢( ..conditional expression.. )/DATA 
WORK¢( ..conditional expression.. )/WORK 


etc. This method certainly pays off when you want to remove duplicates from a 
list which has relatively few unique elements. For example in a 500 X 2 table, with 
only eight unique rows (see Chapter 8 for a listing of ‘UNIQUE’): 


MAT¢(1 1 &<\MATA.=QMAT)/MAT 2.8 s 


MAT<UNIQUE MAT 31 ms 


This last example really illustrates the need to think about everything you do in 
APL; in FORTRAN or PL/1 you are talking about a factor of two or three separating 
the inefficient from the efficient, in APL it may be a factor of 1000! 

I hope these examples will help you to get at least a qualitative impression of the 
way you can trade off the interpreter’s time against overall execution time. How- 
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ever, I don’t think that there can ever be any substitute for your own experience; 
write yourself a function such as 


TIME FN;ADI;7 


C1] aTIME SPECIFIED OPERATION 


[2] T-DAI[2] 

[3] ADJ+DAI(C2]-7 

C4] T+QAI(C2) 

C5] ¢FN 

[6]  'TIME WAS ',(¥*2+(QAI[C2]-2)-ADJ),' MS! 

v 
and get into the habit of investigating functions as you write them. You will certainly 
give yourself a few surprises, but it won’t be long before you develop a pretty 
accurate instinct for the quickest of a range of possibilities. Incidentally this is one 
area where APL really scores over a batch system - in APL you can see a function 
which is crawling. It never really bothered me whether my PL/1 jobs took 1 s or 
30 s of CPU; if you’re waiting 3 h for a batch run you don’t tend to fret about the 
odd 5 min of run-time! In APL a dialogue can stand or fall by response times, and 
the incentive to drive the machine as fast as possible is very powerful indeed - slow 
systems irritate users and stand a very good chance of being thrown out! When did 
you last hear of a batch system being abandoned because it used too much CPU? 
Having looked in detail at many of the factors which influence the speed (or 

otherwise) of an APL program, I now want to offer some rather more general 
advice on ways of speeding up your APL code. 


@ Point 1. The amount of worry due to any piece of APL code is directly pro- 
portional to the number of times it is executed. It sounds obvious, but it is all 
too easy to spend hours optimizing the code in an obscure error routine which 
may never be called. When you are trying to speed up code, avalid assumption 
is that users don’t make mistakes! 


@ Point 2. Keep it simple. The more exotic the APL primitive, the less the 
chance that someone has bothered to optimize it! Stick to the common 
inner products where you can, and beware of flights of fancy with the outer 
products and dyadic transpose. Don’t be afraid to split complex expressions 
over two or three lines, and don’t be afraid of loops where the alternative 
involves the creation of large redundant objects. 


@ Point 3. Look out for quirks in the interpreter. Division of zero by zero is a 
good example: 


A+(200p 2.34 0) + 200p 5.67 O 1.25s 
A«(200p 2.34 5) + 200p 5.67 8 AA aie 


@ Point 4. In general ‘closed-form’ code is better than looping code. I hope the 

exceptions in this chapter will serve to prove this particular rule. The same 

applies to the use of null operations (see Chapter 4) to obviate the use of 
branching, but again you should be aware of the exceptions. 
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@ Point 5. Be aware of the way APL shuffles storage around. In particular, it 


always pays to use indexed assignment into a pre-allocated matrix if you know 
beforehand how many elements to expect. 


è Point 6. Don’t get carried away trying to make APL look like a bastardized 


version of PL/1. For example you could define ‘IF’ and ‘THEN’ functions to 
allow expressions like: 


IF 'LINECT>60' THEN 'ANEWPAGE PC+PC+1 <> LINECT<0! 


Let a good notation stand on its own two feet, and don’t insult it with this 
sort of miscegenation! The statement above is much better left as 


+(LINECT>60)+0K 

LINECT+¢0 

ANEWPAGE PC+PC+1 
ORS. ces 


etc., which will execute a lot faster into the bargain. 


è Point 7. Keep a reasonable amount (say 5OK-100K) of workspace free; 


some APL functions switch to much slower alternatives if you constrain 
them too tightly. You may also find that the storage management runs quicker 
if it has a reasonable freedom of choice. 


@ Point 8 Take advantage of full-screen management. Any application which 


involves complex data editing will probably be five to 10 times faster if the 
screen is used properly. Chapter 9 gives more details, and some examples. 


@ Point 9. Don’t over-validate. Users are intelligent, careful people who occasion- 


ally hit wrong keys. It just isn’t worth spending CPU cycles protecting them 
from strange exotics like 


AE Or SA 


which would slip through a simple-minded numeric check. If you have error- 
trapping then use it as the final long-stop; otherwise be prepared for the (very 
occasional) phone call when someone manages an ‘EXECUTE SYNTAX 
ERROR’. They won’t do it again! 


@ Point 10. Educate your users. This applies particularly to full-screen systems, 


where it might be possible to do half an hour’s work without a single depression 
of the ‘Enter’ key. Make sure users know that they don’t need to ‘Enter’ 
every time they finish a field! In teletype systems you can still pick up some 
CPU by ensuring that everyone makes the best use of command stacks, 
abbreviated prompts, etc. 


That ends this chapter on efficient use of CPU time. The next chapter covers the 
related topic of efficient use of storage: often this too can be traded off against 
CPU time, and I shall again try to show where the balance lies. 


Chapter 12 


Managing the workspace 


In this chapter I am going to discuss two loosely related topics: structuring your 
data to make the best possible use of the workspace available, and getting at data 
which lies elsewhere in your computer system. First let me apologise in advance 
to all those who are exponents of data analysis. In my discussion of APL data 
structures I shall be forced into some thoroughly unrigorous treatment of a very 
exact discipline, and I hope you will forgive the trespass on your territory. 


Structuring APL Data 


It may be that you have the kind of brain that will cope happily with abstractions, 
and that a discussion based on n-tuples, entities, and relations is all you want to 
see. Personally I find it quite impossible to visualize data in such abstract terms, so 
I am going to sacrifice rigour for comprehensibility, and confine myself firmly to 
‘real-world’ examples. 

The simplest possible representation of data is what we might call the ‘card-file’ 
model. Let us represent the sales of six products in four areas, month by month 
over a series of years: 


RES S 


— 
AREA 4 


RIN ASSSNS 












: 


|| FE 
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Each cabinet contains the data for a whole year, and has one drawer for each of the 
four sales areas: 





In each drawer there are six divisions (one for each product), and within each divi- 
sion there are 12 cards, recording the sales details (quantity, price, comments, etc.) 
for the product in that month. 

To represent such a structure in APL is simplicity itself: 


SALES¢ 0 4 6 1290 
SALES¢SALES,[1] YEARONE 


etc., and similarly for PRICE and any other quantities. 
It is also absurdly easy to answer questions such as the following: 


@ ‘What did we sell in Area 2 in Year 3?’ 
ANS¢+/,SALES[3;2;33] 

@ ‘Can I have the figures for March for Product 5?’ 
SUBSET+SALES[ ; 3533] 

@ ‘What is the highest value sale we have ever made in Area 1?’ 
[/,SALES( 31;;]xPRICE(L31;;] 


And so on. This data model is superb for everything from simple query to quite 
complex analysis, and I have used it successfully for a number of applications. 
However, it has several important limitations, and cannot be used for everything: 


è It will waste a lot of space for ‘sparse’ data. If you only sell Product 3 in Area 
2 in Spring, then SALES is going to contain an awful lot of zeros! 


© It is not easy to adapt it to reflect a change in market structure. You cannot 
easily replace all your four-drawer cabinets by five-drawer ones just because 
someone has pioneered a new sales area! 


The next level of sophistication is what might be called the ‘single-table’ model. 
Before I show how the sales information might fit into this, here is an example 
from another field which shows the elegance of the ‘single-table’ approach more 
clearly. 

To keep a record of a company’s employee details, the data structure could be 


145 


JONES A 
SMITH C 





Here each ‘data entity’ is held in a single APL variable, which may be a simple vec- 
tor (ASALARY) or a character matrix (even better a vector of vectors; see 
‘Nested arrays’ in Chapter 14). The complete details of each employee can be found 
by selecting the corresponding elements (or rows) from each object in turn. Each 


row can be identified uniquely by a ‘Key’ variable or variables (AEMP in this 
case). 


As a structure for data enquiry, the single-table model is again simple and 
effective: 


@ ‘What is the average salary of employees over 35?’ 
AVERAGE (AAGE>35)/ASALARY 

è ‘How many people work in Accounts?’ 
+/ADEPTA.="ACCOUNTS! 


@ ‘Can I have a list of all employees, in order of salary?’ 


LIST¢(AEMP,' ',ANAME)[AASALARY; ] 


Applied to the ‘sales-by-area’ data, the single-table model gives a considerable 
economy in storage, at only slight cost in complexity. The model would now look 
like 


SS Sen Se Se Se SS SoS SoS SS SSeS SSS SS Ss SS eS Se SS 


i! 
n veor _| Ooae O 
1 

iL 80) l 

„| 80] 

i! i 

1l --1 | ' i 

l AMO ' 
t 
H 
i 


J 


AAREA A PRODUCT 





yt AYR 





KEY 





eSa aaa ae 


The main gain is clearly the saving in storage (assuming we only create a table entry 
for a non-zero sales figure), but this model can also react more easily to new areas 


and new products. However, simple enquiries and summaries are not quite as 
simple as they were: 


@ ‘Total of sales, split by area...’ 


TOTAL¢SALES+ .xAREA° .=ı[ /AREA 











146 


@ ‘What did product 3 do in June?’ 


SUBSET+¢( (PRODUCT=3 ) AMO=6) #YR,(€1.5]JSALES 


It also fails to record prices for products that don’t sell! The solution to this 
anomaly (and others like it) is discussed in the next section. 

For an application of this type, I would suggest the ‘card-file’ model where you 
are interested mainly in enquiry on stable data. The ‘single-table’ model may be 
forced on you by lack of workspace, but it does have the advantage of easy up- 
dating and modification. A further point in its favour is that it fits in very nicely 
with the concept of component files; each APL variable becomes one entry on the 
file and need only be brought into the workspace when required. 

I want to concentrate now on the employee-record example, and to develop the 
single-table model rather further. The first concept to introduce is the ‘reference- 
table’, the need for which becomes apparent when you consider questions like 


eè ‘Employees over 30, sorted by department’ 
@ ‘Who is responsible to Bloggs?’ 


The trouble with the single-table model is that it leads to unnecessary repetitions ; 
many employees will work in the same department, and each department will be 
uniquely associated with a manager. What we must do is remove ‘Department’ 
(and anything related to it) to a separate table, linked to the original table by a 
pointer vector: 


JONES A 
SMITH C 


ANAME 













BLOGGS F 
AMANAGER a 


As we shall shortly see, the ‘reference table’ is really only a special case of a much 
more general way of linking related data. 
The sort by department is now very easy indeed: 


NAME[ AADEPTPTR; J 


but more important is the saving on workspace, and the greater ease with which the 
main table can be updated. It is obviously vital that every employee has a valid 
department, and with a reference table this can easily be verified using a function 
such as ALKP (see Chapter 8) which won’t even insist on the full department name. 
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The single-table model would be very vulnerable to 


D3351 ACCOUNTS 
D3352 ACCOUNTING 


where two people have slightly different ideas on the name of the same department. 
This new model has the additional advantage that it will cope quite happily with 
the unlikely occurrence of a department which has no employees! 

The reference table also allows you to change any department-related infor- 
mation - such as a change of manager - without touching the main table at all, 
which can be very useful if you are moving data to and from file. So what’s the 
catch?! Well, consider what happens if you want to add a new department between 
‘Wages’ and ‘Computer’: all the pointers to ‘Computer’ (and departments following) 
will have to be increased by one. Similarly, before you delete an entry from a 
reference table you must first check that nothing is pointing to it; if you delete it 
anyway, you must take some action about any such rows. 

Once again we have gained in efficiency of storage and enquiry, but this time the 
cost is increased complexity during update. 

The second refinement to the single-table model is something I would call a ‘link 
table’. Again taking the staff record as my example - suppose we want to keep a 
training log for each employee. The company has several different courses, on which 
employees are sent, so one clear requirement is a table for each of these: 


MARKETING 
FINANCE 








The question is, how do we link the employee table to this? Each employee may 
have been on many (or no) courses; likewise each course will have been attended by 
varying numbers of employees! A simple pointer system just will not cope, so this 
is where the link table comes in - it will look like 


pro oct ------------------——- 
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i.e. one entry for each occasion any staff member goes on any course, with pointers 
in both directions. Some people/courses will have no entries at all on the link table, 
some will have many, but each employee-course pair will uniquely identify a 
date - the date Joe Bloggs was sent to learn about Creative Thinking. The data 
model now looks like 
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It now becomes clear that the table-table relationship is really only a special case 
of the more general table-link table: the STAFF-DEPT link could have been - 


defined as 
AEMP|ADEPT 
APTR|APTR 


but, because of our insistence that each employee has exactly one department, 
AEMPAPTR is simply a permutation of 11tpAEMP! Without loss of generality we 
can sort by employee and put ADEPTAPTR on the end of the employee table. 

In my experience, these two elements (table, link table) are ideal building bricks 
for the typical APL database. I know this approach to data modelling lacks the 
rigour of a genuine relational analysis, but it almost invariably results in an equiva- 
lent representation, it is very easy to handle, and extremely flexible. Because the 
links follow strict rules (which are independent of the model as a whole), you can 
use standard code to maintain each type of link. 

To maintain the integrity of the data requires the application of only two simple 
rules: 





@ When the keys in a table are re-ordered, all pointers (whether from link table 
or main table) must be changed to match. 


@ When a row is deleted from a table, then one of two things must happen: 
anything which previously pointed to it must either be deleted, or must be 
re-routed to a ‘catch-all’ row with a value indicating ‘unknown’, In general we 
would probably tolerate such an implicit deletion from a link table 
(COURSELOG), but not from a main table (STAFF). 


Fortunately, both these rules can be obeyed rather easily - the trick goes something 
like this: 


e First create a dummy key (which the user never sees) which is simply the 
integers from one up to the number of rows in the table. 
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@ Allow the user to make any changes he likes (deleting/adding/re-ordering) to 
the table; whatever he does to it, you do the same to your dummy key. 


@ When the changes are complete, you first delete (or re-route) any rows 
where the corresponding pointer no longer occurs in the dummy key. You 
then look up the pointer in the dummy key to obtain the new values for that 
pointer. 


At this point it should (I hope!) be becoming clear where the power of this data 
model lies. It is the interconnections that can bog down any data base system, and 
this model has only one type of connector: 


i.e. a many-to-one connector. This means that as long as you stick to these building 
bricks you can put together a database of considerable complexity, and be confi- 
dent that it will work! Even more important, you can modify it just as easily 
- clearly it is a very simple job to add new entities to existing relationships (i.e. 
new variables to existing tables, pointers or variables to existing link tables, etc.), 
but it is also not difficult to add completely new tables, or to change the links 
between existing ones. In fact I have a suspicion that the whole process should be 
automated: all we need is a conversational database editor to help establish (or 
change) the relationships, which will then write the code for us. Any volunteers 
- I’ve got a book to finish! 

This chapter is really about data maintenance, but I clearly cannot escape with- 
out some reference to the way that data might be used. First, access is possible 
through the main table, to produce a list of the courses attended by selected 
employees: 


Employee Name Dept Course Date attended 
A6215 A SMITH OP RES CREATIVE THINKING 21/03/79 
FINANCE 03/07/80 


The other obvious route to the data is through ‘COURSE’, to produce a similar 
list, but showing the employees who attended selected courses: 


Course Description Attended by Date 
A301 FINANCE A SMITH 03/07/80 
B JONES 03/07/80 


To achieve these results, we need one further component in the data model, but 
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fortunately it obeys the same rules as the bricks we already have - it is the ‘selec- 
tion’, which may point to any table, using a simple one-to-one relationship. It could 
be updated explicitly by functions such as ‘SELECT’ or ‘SORT’ and implicitly 
whenever the table it pointed to were changed. 

Obviously there is scope for far more sophisticated selection and presentation of 
data than I have shown here, but the principle remains the same. By formalizing 
data in this way, you lay firm foundations for the future evolution of the kind of 
decision-support system I outlined in Chapter 2. Working within a flexible frame- 
work which guarantees the integrity of your base data will give you far greater free- 
dom in that vital phase of ‘programming by negotiation’. 

In summary, any collection of APL objects can be gathered into logical relation- 
ships of only three types: 


@ Selections - which simply pick out rows from tables. 


@ Tables - which consist of a key (usually, but not always, a single variable), 
and anything related to it. These objects may be simple data, or pointers to 
other tables. (Pointers are only allowed in the special case where a table entry 
has one - and only one - corresponding entry on another table.) 


© Link tables - which consist simply of related objects, where many (or no) 
rows of a link table may be related to one or more tables. A link table may 
only be updated through the main-table entries to which it points, and it may 
be used in displays from any of them. 


Having outlined what is effectively a poor man’s approach to relational database, 
I now want to take an equally unrigorous view of relational analysis! Given a 
bucketful of assorted data, how do you set about sorting it into sensible groups 
(tables and link tables)? 

The first stage is to isolate the key objects which will serve to identify each row. 
Having done this, you can hook on to these keys anything which is related to them. 
Anything left will have to find its way into a link table, which is where it gets 
tricky! I think another example is appropriate here, so here is a bucketful of half- 
rationalized data: 


JOB NUMBERS/DESCRIPTIONS 

SUPPLIER NUMBER/LOCATION 

SUPPLIERS’ PRICE LISTS 

OUTSTANDING ORDERS TO EACH SUPPLIER 
PARTS NEEDED FOR EACH JOB 

PART NUMBER/DESCRIPTION/STOCK IN HAND 


Here I have isolated three tables; this is as far as we can go without some thought 
as to how the data is going to be used. 
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The first obvious view of the data will be that of the engineer, who will see JOBS 
composed of PARTS obtained from SUPPLIERS: 
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Now many suppliers probably supply the same parts, but at different prices, so the 
bridge between PARTS and SUPPLIERS must look like 
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PARTS PRICE LIST 


l 
APART li 









i.e. the price is implied by the combination of part number and supplier; neither 
will do on its own. This also reflects the view of the buyer, who sees SUPPLIERS 
with catalogues of PARTS. 

Similarly, there may be several ORDERS outstanding (for the same PART) to 
different SUPPLIERS (The project planning department may well see the data in 
this light): 


ORDERS t=- --- -22L 


- = -m y = d 





Each ORDER will be the result of a requisition from a particular JOB (the accoun- 
tant’s view?): 
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Which completes one possible analysis. This final data model is 
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But it is by no means the only one for this data. However, it can answer a wide 
range of queries, such as 


è ‘If supplier 345 goes on strike, which jobs might be affected?’ 
e ‘Who supplies us with left-handed sprockets, and what are their prices?’ 
è ‘Have we enough widgets to finish Job 678?’ 


This final model really is quite complicated, but it does ensure integrity (for 
example it will retain the information about prices and suppliers for parts not cur- 
rently on order), and it does provide the means to project the same data to satisfy 
many different viewpoints. Data design is bound to be influenced by the processes 
you think you are going to do on it; with a well structured relational model (which 
the PARTS-JOBS-SUPPLIER model is) you know that you have retained the maxi- 
mum possible flexibility, which is an excellent base from which to negotiate a 
system. 

Two final examples, starting with another view of the EMP-link-COURSE data. 
Supposing that it matters to the company which department an employee was in 
when he went on a particular course? In practice this is quite likely, because if he 
moved halfway through the year it would be unfair to charge his new manager with 
the total training cost! To change the model to reflect this new requirement is 
simplicity itself - the tables stay the same; only the links need to be altered: 


Desc. 





7 


r--------- 


Lastly, there is the old chestnut of plex-structures (parts explosions, critical path 
networks, etc.). These provide a fascinating example of tables where many entries 
are related to many entries in the same table! Take, for example, workspace docu- 
mentation: 
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Chapter 10 (see Figure 10.6) illustrates how easy it is to draw the workspace struc- 
ture from data stored in this way (having first screened out recursive calls!). Rela- 
tional analysis may be no more than applied common-sense, but it is a tool no 
self-respecting APL programmer should be without. 


Getting at External Data 


I am going to close this chapter with a few notes on a very tricky subject: your 
company has lots of nice data which you would love to get at from APL - how do 
you do it? Here are four possible methods, all suitable for slightly different needs: 


@ Print it out, and key it in again! This is by no means as daft as it sounds; if 
you are implementing a production planning system for a couple of products, 
then why bother automating a process that will only take 10 minutes any- 
way? It also has the advantage that the person doing the keying will have his 
attention brought to any odd figures as early as possible. The disadvantage is 
that he might make some typing errors, or might ‘bend’ some of the figures 
to what he thinks they ‘ought’ to be. 


e Do a ‘one-off sequential-read, thereafter maintaining the data as above. APL 
just isn’t suited to ploughing through files one record at a time, but you may 
get away with it once a year. This is a suitable approach when you want to do 
a detailed analysis on some historical data, which may only change every 
couple of months anyway. 


@ Use a conventional APL system to create a batch job (in COBOL, PL/1 or 
some special purpose database query language) which will go off and do a 
selective retrieval for you. This subset file will still be in the ‘wrong’ format, 
but it will be a far more manageable size than its parent. You can also ask for 
the output to be blocked up toa reasonable length (e.g. 50 X 80 byte records) 
to speed APL’s access to it. This technique might be used if you wanted to 
analyse parts of a very large data bank, for example the monthly sales of 200 
products over 10 years (say 25 000 records on a conventional file). To find 
out about left-handed sprockets in 1975 you create a batch job which selects 
the relevant 12 records (in no time flat if its’s PL/1) and places them end to 
end as a single output record. The overall elapsed time for all this is probably 
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less than APL would take simply to read the original file, and the economies 
in CPU time are enormous. 


@ Design a general purpose file-inversion program which will accept any sequen- 
tial file as input, and will use parameters to extract the fields of interest. An 
excellent repository for the output is IBM’s VSAM file system, because 
you can use your APL variable names as the file keys. For example the inver- 
sion of a personnel records file might be represented by 
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Once the output file has been produced, it can be accessed very efficiently 
from APL, and data can be retrieved conveniently by name: 


FETCH 'AGE , SALARY"! 
AVERAGE SALARY WHERE AGE >35 


where ‘FETCH’ uses the names supplied to key to the file. My one reservation 
about file inversion is that it is very difficult to design a program which will 
deal efficiently with both short, fat files and long, thin files, not to mention 
a wide variety of database systems. Heavily used data may often justify a spe- 
cific inverter, tuned for maximum efficiency for that file only. 


So I must draw to a close this chapter on data management with APL. It is a fas- 
cinating subject, and one which is still very much in its infancy. As workspace sizes 
increase to hitherto unheard of values (who would have believed 16 megabytes in 
APL\360’s early days?) it is a subject which will become increasingly important, 
and in five or ten years’ time it should be possible to implement quite large data- 
bases entirely within the workspace. Now there’s a management information tool 
worth talking about! 





Chapter 13 


Towards the mechanized office 


‘Office automation’ has been one of the buzzwords of the late 1970s. It conjures up 
‘visions of managers deeply involved in an international tele-conference, while their 
respective secretaries exchange memos on a network of communicating word- 
processors. All these scenarios abound with technological marvels, each designed to 
speed up some specific office task, but will they really lead to a more efficient 
business? I rather doubt it, and the rest of this chapter explains my reservations 
about this kind of office automation, and outlines the role that I think APL can 
play in the future mechanization of office functions. 

The first thing to realize is that an office does not exist to give people the 
opportunity to fill in forms, type memos, file documents, etc. It exists to perform 
some kind of business function (selling things, controlling stocks, invoicing custom- 
ers), and it does so by making the best use of the available tools (filing cabinets, 
forms, typewriters, spikes on the wall). Let me quote again part of the passage I 
quoted in Chapter 2: 


‘, . . the sum of the optimal solutions to each component problem is 
not an optimal solution to the mess as a whole.’ 


All the word-processor optimizes is the process of putting words on paper; it may 
contribute to an overall improvement in efficiency, but there is no reason why it 
should. In fact it may reduce efficiency by flooding some other office with redundant 
paperwork! The question we should be asking is not ‘What is an office?’ but ‘Why 
is an office?’ We can then begin to make some progress towards using our techno- 
logical marvels to improve the overall office function, rather than simply speeding 
up the tasks currently used to achieve that function. Unfortunately, this is very 
easy to say and very difficult to do! 

The problem is that there are as many different office functions as there are 
offices, so we are faced with the daunting prospect of writing specific, high-level 
tools for each and every office. By focussing on tasks, the manufacturers of word- 
processors, copying machines, etc., have found a large and lucrative market (tasks 
being pretty standard things), but I doubt very much if they have contributed the 
hoped-for gains in overall efficiency. They may indeed have increased ‘the number 
of pages per secretary per day’ by some impressive factor, but how much of this 
‘productivity gain’ is really due to Parkinson’s law (‘Work expands to fill the time 
available’)? They may have doubled the ‘pieces of mail logged per hour’, but how 
much of it is piling up elsewhere, unwanted and unread? Such artificial measures of 
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task performance are at best useless, and at worst misleading. To justify any form 
of office automation we must look for ways of improving the office function, and 
ways of measuring this in terms of overall business objectives. If you can present a 
case in the form, 


‘By improving certain production planning functions we can help the 
company to reduce stocks of materials, whilst also cutting down the 
number of occasions we run out of finished goods.’ 


then you should go ahead, even if the actual financial gain is hard to quantify. If 
your solution can be assembled entirely from generic tools (word-processors, text 
retrieval systems) available cheaply off the shelf, then so much the better. This 
might apply to a system at the very top of an organization, say to help the managing 
director’s secretary, but lower down in the murky waters of short-term planning 
and production management you are most unlikely to find an ‘off-the-peg’ system. 
It is here that I come full circle to the philosophy of Chapter 2, and the methodology 
of Chapter 6; I believe in APL as the ideal, all-purpose, generic tool with which we 
can build the functionally specific systems needed for true office mechanization, 
and that really is what this book has been all about. 

Before I go on to explain this belief, I must define some of the terms I have so 
far been using rather too loosely. In particular I must make clear the distinction 
between (a) a task and a function; (b) automation and mechanization; (c) generic 
and specific tools. Here I am going to follow the definitions of Hammer and Zisman 
(1980) from their paper ‘Design and implementation of office information systems’. 


e A task isa simple, narrowly focussed activity; a function is an end realized by 
means of task performance. In general, we can say that a tool is used to help 
perform a task, and a system to help realize a function. 


èe Automation implies the use of machines to replace people; mechanization 
implies the provision of improved tools to help people to perform tasks 
better. Examples of true office automation include most of the early DP 
systems, like payroll and accounting; examples of mechanization would be 
computer-aided design, visual interactive simulation, etc. 


© A generic tool (typewriter, filing cabinet) is not tailored in any way to a 
particular application; a specific (or custom-built) tool has some knowledge 
of a particular system built into it - this makes it much more powerful for 
that particular application, but sacrifices all the economies of scale as a result. 


Functional systems are built from some combination of automated and mechan- 
ized tasks, using generic tools where available, and specific tools otherwise. With 
APL we can provide the generic tools (desk calculator, word-processor, data manage- 
ment, text retrieval), and build the specific ones (production scheduling, materials 
planning, sales forecasting) all within one environment. That is one reason why I 
believe APL has a future in office automation; another is communication - by this I 
don’t just mean communication between people (although that, after all, is what 
APL was designed for), but communication between systems. 





163 


There seems to me to be one crucial factor missing from many otherwise credible 
scenarios of our automated future. In the enormous diversity of species emerging 
from the primal slime of the electronics revolution, there is an almost wilful desire 
to invent new protocols, new data formats; we are building a Tower of Babel to 
dwarf its biblical predecessor into total insignificance! The mathematics of the 
situation is straightforward enough: in a network of N nodes, the number of edges 
is given by 


EDGES¢.5xNxN-1 


It is the implications of this innocent-looking formula that we must not overlook. 
Consider a company, already the proud possessor of a word-processor, which 
purchases a similar machine from a different manufacturer and wants to link the 
two. It now has two nodes, one edge, and requires one protocol-converter. Should 
it purchase a third machine, it will have three nodes, and three edges; a company 
with 10 such devices has 10 nodes and up to 45 edges to its network. To add just 
one more box could trigger a demand for 10 more interfaces; already a large pro- 
portion of the total processing power of the network is being consumed internally, 
and as more nodes are added its productivity will tend rapidly to zero. Of course 
no company would deliberately get itself into such a mess; the trouble is that 
each machine is bought separately to satisfy a local need; it is not until later that 
someone sees the possibility of linking them up, and by then it is too late to change. 

Perhaps we could learn a lesson from the early days of the British Empire in 
Africa: when a 50 mile stretch of railway was laid in Egypt, it was built to the same 
gauge as a similar length near Durban, some 4000 miles away! I don’t know if they 
ever did link up, but at least the potential was there. APL many not be the ideal 
solution to your word-processing problems, it may not be the best text-retrieval 
tool on the market, but it can at least do all these things reasonably well. What’s 
more it can share data effortlessly across an unlimited number of apparently 
unrelated applications, allowing wholly unexpected fusions and cross-fertilization 
to occur. No longer will it be necessary to copy figures laboriously from computer 
printouts, simply to have them re-keyed as part of a ‘neat’ report. The text of 
Chapter 8 exemplifies just this point: using my ‘A’ editor as a word-processor I 
have gone from executable (and tested) APL code straight to the printed page, with 
no manual intervention in between. The advantages are a considerable saving in 
time and effort, but more importantly a guaranteed freedom from transcription 
errors. Providing such a service for a production planning department may give a 
far better return in timeliness and accuracy than the most sophisticated of OR 
models! 

Here, then, is my scenario for the future; it is (of course) an idealization, and I 
shall list the snags in a moment, but it does at least give us something at which to 
aim. First, I would like to see a far greater dispersion of the hardware; a series of 
APL processors, each capable of supporting something akin to APL*PLUS, with 
say 16 megabytes of active workspace. Each processor would support one user 
(the only way I know of getting consistent response times), and data local to an 
application would reside with that processor, being sent down the line for backup 
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as required. Apart from this, communication would be limited to ‘electronic mail’, 
large printouts destined for a central pool of fast printers, and central data shared 
by a number of users. Tasks such as workspace documentation would also run in 
the centre, being triggered from the appropriate user by means of shared variables, 
and thereafter run ‘off-line’ from his point of view. 

New applications will be designed by a team of programmer-analysts, who will 
follow the approach of Chapter 6 to develop systems which address the functional 
needs of the organization. They will also be responsible for detecting the need for 
new generic tools (or ‘packages’ if you prefer) and for enhancing and maintaining 
those already on the shelf. This team will also play a co-ordinating role in organiz- 
ing regular APL workshops, and generally keeping in touch with the APL community. 
As an increasing number of users begin to do their own programming, the workshop 
will supply the need for an efficient clearing house for APL gossip; it will be a place 
for new users to get advice and for old hands to test each others’ APL wits. 

So much for the ideal; what of the reality? Well the hardware I don’t really see 
as a problem; I’ve given up being astonished at processor powers that double every 
three years. In fact the more we can structure the system to minimize user-to-user 
communication the easier it will be to maintain. There is always the danger that, for 
example, a production planner will come to take for granted the availability of a 
nearby printer belonging to the payroll system. Because he has never made a 
formal arrangement to use it, he has no real grievance if it is taken away, but I 
doubt if that will stop him becoming more than a little upset! 

Informally shared hardware is one problem, shared data (whether formally or 
informally) is another. By this I don’t mean the problems of controlling shared 
access to files - these have already been well and truly solved - rather the conflicts 
that can arise between members of a user community who each have a different 
perspective on the same data. Consider the ‘employees-courses’ database discussed 
in Chapter 12. From the point of view of the training department, the data looks 
like 


Course People requiring it 


SKIN DIVING JONES, SMITH 
CREATIVE THINKING BLOGGS, HARRIS, SMITH 


The training department’s objectives will include (a) scheduling courses round the 
known workload of the tutors and (b) ensuring a reasonable number of participants 
at each course. On the other hand, each manager will see the schedule as a way of 
completing his staff’s education at the least cost in departmental productivity. He 
will be concerned to avoid the possibility that both co-authors of a critical system 
may be away simultaneously, and so on. In fact to him the data looks like 


Employee Time committed to... 


SMITH Creative Thinking, Skindiving 
HARRIS Creative Thinking 
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We cannot allow indiscriminate access and updating by both parties; even in asystem 
as simple as this there are clearly visible the seeds of anarchy. In more complex 
databases there may be dozens of different projections of the data, and some 
formal way of detecting and resolving conflicts must be invented. 

These ideas were first (to my knowledge anyway) developed by a colleague in 
OR - Richard Thomas. As his work is as yet unpublished, I have asked his permission 
to quote from it here. He calls the concept ‘Distributed Decision Making’, and 
with it sets out to meet these ideals: 


‘Everybody does their own thing, and yet organizational goals are still 
reached. The point is that you make a decision based on your percep- 
tion of reality, and diffferent people will view the same reality dif- 
ferently. We must try to design an information system so that it lets 
people see a view of reality within which they can take decisions; these 
decisions then get incorporated into the information system, and some 
people may notice them depending on their own reality.’ 


How is this to be achieved? Well, Richard sees the following constructs as fundamental: 
© Database: all the data. 
@ Window: a designed view of the data. 
@ Decision realm: what we allow people to update through a window. 


© Doing box: a personal computing system, linked to the database through a 
window, which helps a person to do his job. 


© Conflict resolver: facilities to detect and resolve opposing decisions, for 
example to act as arbiter when a variable is oscillating as a result of two or 
more people using their ‘doing boxes’ in opposing ways. This could simply 
take the form of exception reports to the appropriate managers. 


His design method closely parallels mine, with the one important addition that 
where multiple users are involved some criteria for the existence of conflict will 
need to be established. Once this has been done (and the database, its windows and 
decision realms in place, has been set up), then the ‘doing boxes’ can evolve in close 
conjunction with the system’s users. | 

At present, I have absolutely no idea how I should set about implementing such 
a system! All I can offer is the haziest of notions that if there is one single tool 
which just might prove up to the task, it is the APL shared variable. Let us imagine 
an APL workspace controlling the database. The decision realms correspond to 
functions within that workspace, and each window to a pair of functions com- 
municating by shared variables: 
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WORKSPACE 





CONFLICT 


RESOLVER 





Decision 
realm 






Decision 
realm 







DATABASE 







WORKSPACE 





One member of the pair is in the host computer, the other is embedded in the 
user’s own workspace, forming part of his ‘doing box’. Of course this may also 
use his personal, local data, and it may have other windows to other databases. I 
know this already slips away from Richard’s definition of the database as ‘all the 
data’, but I feel obliged to compromise this one principle to bring the whole idea 
within manageable bounds. The ‘conflict resolver’ is really a special kind of ‘doing 
box’ which may even be empowered to alter other people’s decision realms when 
it detects certain pre-set conditions. 

Will it ever be done? Not with today’s hardware I’m sure, but given another 10 
years and a few good brains to worry at it and I think we might see something of 
the kind emerging. I shall follow its progress with interest! 

I shall now try to summarize in one paragraph the most important points in this 
chapter. First, true office mechanization demands a view of office function in the 
context of the whole organization. To achieve real productivity gains we shall 
probably be forced to forsake generality, and to create specific tools suitable for a 
very limited range of applications. Secondly, I believe in APL as an excellent way 
of providing such tools, whilst also making available more general facilities such as 
text editing and data retrieval. Thirdly, I don’t think we yet possess either the tech- 
nology or the expertise to implement such ‘holistic’ systems effectively. I propose 
the ideas of ‘distributed decision making’, implemented using stand-alone APL 
processors and shared variables, as a possible pathway towards the future. 





Chapter 14 
Whither APL 


The short answer is ‘I don’t know’, but I’m as willing to take a few guesses as the 
next man! APL stands where it does today as much in spite of as because of the 
efforts of IBM, and even that paragon of capitalist efficiency seems unsure what to 
do next. Having attempted briefly to sell APL on the ‘personal computing for 
managers’ ticket, they now seem to be basing their marketing effort largely round 
APL packages. The time-sharing bureaux, on the other hand, have gone hell-for- 
leather to corner the market in sophisticated data manipulation and econometric 
modelling. By making available vast databases of valuable information (and a 
fileemanagement system to access them) they have clearly established a permanent, 
and very profitable, business. 

Where does that leave the rash of one-off commercial systems I have described in 
this book? Not on time-sharing bureaux, certainly, because of the problems of tele- 
phone lines, and the need to get at company data. On some IBM system on your 
own computer? Well yes, but wouldn’t it be nice to have all those goodies like 
component files and OFMT! On an APL mini, or micro? These are clearly the 
jokers in the pack but haven’t yet appeared in sufficient numbers to make a real 
impact. The microprocessor of the moment is the Z-80, an eight-bit machine, which 
just doesn’t have the muscle to implement a full-scale APL system. Try writing the | 
assembler for floating-point division and you’ll quickly see why! On the other hand 
there is at least one excellent mini-computer APL system already on the market, 
and the next generation of micros is on the horizon. These will be 16-bit devices, 
and will include hardware functions to do the complex arithmetic. They should also 
have features which make screen-handling a positive pleasure; even in Z-80 assem- 
bler it is quite absurdly easy to put together a fascinating variety of ‘video games’. 
Someone, however,:will have to hurry: BASIC is already far too well established to 
be easily dislodged, and unless there is a good micro-APL soon it will be too late to 
make any difference. 

If APL does miss out on the micro-computer scene it will be a big loss both for 
APL and for the micros. Its sheer compactness makes .it an excellent candidate 
for programs which have to be shoe-horned into 2K or 3K of memory, and its 
matrix-handling will make light of video-tennis or ‘Space Invaders’ or whatever. 
Also the shared variable concept seems ideal for a wide variety of process-control 
applications - why shouldn’t you share a variable with your central heating system?! 
This process-control tack is one I shall return to shortly, but first a brief review of 
what is happening back in the APL mainstream. 
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There would seem to be three parallel streams of development: in the language 
itself; in the environment within which it is run; and in the applications people are 
using it for. Sometimes the first two of these overlap, for example VS APL regards 
file access as a feature of the environment, whereas in APL«PLUS it comes as part 
of the language. For consistency I shall follow IBM on this one, and classify any- 
thing not available in VS APL as part of the environment. 

First then, the APL notation itself. There has been astonishingly little change in 
this since APL\360 gained format, execute, and scan, and became APLSV. In the 
early days APL was IBM, and any change to the language was, by definition, 
adopted universally. Today it is more difficult, and anyone who invents a really 
worthwhile extension to the notation is going to have a hard job persuading all the 
manufacturers to adopt it. Two recent examples spring to mind: APL*PLUS with 
‘Replicate’ as an obvious (when someone else has thought of it!) extension of 
‘Compress’: 


1 2 0 1/'ABCD! 
ABBD 


The sooner this one goes on general release the better - I have lost count of the 
number of times I have had to program round it with some wasteful construction. 
Another interesting idea comes from GEC, with their 4000 series mini-computer 
APL: 


pBe1 O 1 wA¢3 49112 
314 


They have used omega to give a way of expanding the rank of an object. This makes 
the vector to one-column matrix job a great deal easier: 


MAT<1 0 wVEC 


and, combined with their more relaxed view of conformability, we can multiply a 
matrix by a vector very simply: 


MAT+¢MATx1 OwVEC by column 


MAT+¢MATxO 1wVEC by row 


The problem with this is that alpha and omega are already spoken for by Ken 
Iverson for his idea of direct functional definition, so here is one for the inter- 
national committees to chew over. Incidentally, why has no one ever copied the 
Burroughs 700 construction: 


MAT¢MAT+(1] VEC 
MAT<MATx(2] VEC 


with the default of [2], i.e. the last dimension? It can’t be that difficult to let all 
the scalar dyadics take an axis operator. 

Two other things to mention are the use of ‘diamond’ to put several statements 
on each line, and the ability (available on APL\360 and lost thereafter) to append 
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comments to existing lines of code. Both of these make obvious sense when you are 
working with a screen 79 columns wide but only 24 rows deep. Few APL state- 
ments go beyond column 30, and it is an absurd waste to have to add extra lines for 
comments when there is ample space in the right-hand margin. In fact I have almost 
given up commenting the body of the code, confining myself toa hefty comment at 
the top of the function. I find it more helpful to be able to see the entire function 
on one screen than to have each line individually described. For one thing, it is not 
always obvious if a comment refers to the line immediately above, or immediately 
below! 

The same applies to the use of ‘diamond’, with the additional advantage that this 
can be used to group logically related statements. For example, if ‘STOCK’ and 
‘SALES’ have been passed to a function as rows of ‘INFO’, 


PROD+SCHED INFO;STK;SLS 


[1] aSCHEDULE PRODUCTION TO MEET EXPECTED DEMAND 


[2] STKINFO[1;] <> SLS+INFO[2;] 


etc., not only saves space, but adds considerably to readability. 

Finally ‘nested arrays’, which may be the most exciting language development 
of all. The one area where I have always found APL rather weak (at least in com- 
parison with PL/1) is when handling structures of data. For example the staff 
table of Chapter 12 contains a variety of disparate APL objects: 


AEMP numeric vector 
ANAME character matrix 
ASALARY numeric vector 


The process of compressing across ‘STAFF’ is made tedious by the necessity to 
treat each object individually; if it were possible to create a matrix consisting of 
vectors ‘AEMP, ANAME’, each enclosing the contents of the ‘nested’ variable, 


STAFF¢MASK/STAFF 


would be a far more natural (as well as more concise) way of removing a row. 
Similarly, to select employees earning over £5000: 


(5000<>STAFF(33;])/#STAFF[E 31 2] 


For more details, see Smith “Nested arrays: the tool for the future”, one of a 
number of papers collected in a volume entitled APL in Practice (Wiley, 1980). 

The next thing to look at is the APL environment, and here I am going to 
include all the borderline cases like system functions and system variables. As far as 
the hardware itself goes, the slogan seems to be ‘bigger, faster, cheaper’; APL will 
benefit from all of these, but particularly from ‘bigger’; as core is replaced by fast 
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semiconductor memory, APL’s voracious appetite for workspace will finally be 
sated. There are two other hardware developments I shall follow with particular 
interest: ICL’s distributed array processor and (also at ICL) content-addressable 
memory. DAP could suddenly transform APL from being on a par with conven- 
tional language to being about two orders of magnitude faster; CAM is the ideal 
vehicle for the APL relational database from Chapter 12. In fact ‘A=’ effectively 
is CAM, but in core! 

Looking now at operating systems, I find myself relentlessly drawn back to IBM. 
It is their declared intention to make VS APL look the same wherever you find it 
(currently TSO, CMS, CICS, VSPC), but they still have a long way to go to doit. 
The bureaux, on the other hand, have diverged rapidly from VS APL, and have 
developed shoals of quad functions to handle everything from error trapping to 
file access. In the short term this is clearly to their advantage, but it does clutter up 
the language with a lot of very un-APL instructions. I know IBM’s way of pushing 
everything out into auxiliary processors is harder to work with, but it does preserve 
the purity of the original concept. It would, however, be very convenient to have 
facilities like )LOAD and )COPY as part of the language, rather than messing about 
with an input stack. Automatic ‘house-keeping’ on the symbol table would be very 
welcome too, or at the very least some way of clearing it without the rigmarole of 
‘\CLEAR, )SYMBOLS, )COPY, )WSID, )SAVE’. I know of at least two occasions 
when ‘)CLEAR, )SYMBOLS, )WSID, )SAVE’ has lost a day’s work! I’ve no idea 
who will win this one, and I don’t really care, as long as all the necessary facilities 
are made available one way or the other. On the whole it seems likely that VS APL 
will have to follow APL+#PLUS, this being the only way IBM will pinch back signi- 
ficant amounts of business. 

I know this is supposed to be a look into the future, but it seems to me that a 
brief review of the various IBM environments might be appropriate here. VS APL is 
currently a fully supported ‘program product’ under CICS (a transaction processor 
designed for online enquiry/update), . VSPC (a time-sharing supervisor running 
within MVS - IBM’s main batch operating system), and VM/CMS. This last provides 
every user with his own ‘virtual’ computer, and a cut-down operating system with 
which to drive it. 

VS APL can also be found (and frequently is!) under TSO, which is effectively a 
full-scale, time-shared operating system. Of the four, CICS is very much a way of 
getting a few people hooked (‘Not more than six concurrent users’ say IBM, and I 
believe them), and TSO is thought to be a bit long in the tooth, and probably on 
the way out. That leaves VM/CMS and VSPC, which (as environments for APL) are 
superficially similar, but there are some quite important differences in detail. 

First the similarities - both support execution of host commands; use of local files 
(APL format and EBCDIC); full-screen; input stack; and external VSAM files. So 
far, so good, but life is rarely as easy as that! The two most obvious differences are 
that CMS provides an easy route to ‘off-line’? APL (VSPC does not), while VSPC 
supports user-to-user shared variables (CMS thinks everybody is 1001!). Another 
noticeable contrast is in the maximum workspace available: it is a generous 16 
megabytes under CMS, and 4 megabytes with VSPC. 
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The less obvious differences only become apparent when you want to do some- 
thing slightly subtle, such as imitating APLxPLUS’s component files. CMS handles 
direct access, variable length, APL-format files - which is just the tool you need; 
VSPC does not. Under CMS you have a complete ‘virtual system’ to go at, with 
card-readers, card-punches, and printers; getting a deck of cards ‘into’ VSPC is a 
work of art! As for routeing output to fast printers (or remote work-stations), it can 
be done under VSPC, but you won’t find it easy. The other major contrast is in the 
hosts themselves, with CMS providing a powerful ‘EXEC’ language, and VSPC a 
somewhat feeble-minded equivalent. Even as simple an operation as clearing the 
screen becomes a labour of love in IBM’s flagship of ‘personal computing’. 

Finally, how do the two compare on the one yardstick that really matters: 
response time? I can do no better than to quote from ‘Making the inhouse decision’, 
again from APL in Practice: 


°VM/370 is a superior interactive time-sharing system with terminal 
response time in the two second range . . . . MVS is a superior system 
for batch processing and an adequate system for an ancillary, low 
volume time-sharing workload (if five-second response time is accept- 
able to the user community)’. 


Enough of IBM! There is one more feature of the APL*xPLUS system which 
holds fascinating possibilities - ACE or ‘Automatic Control of Execution’. This is 
effectively a way of running APL jobs automatically in a kind of quasi-batch mode; 
it makes obvious sense for regular production runs, and for heavy one-offs like 
workspace documentation. However, it also raises the possibility of concurrent 
processing, where several active workspaces co-operate (using shared variables) to 
achieve a result. It is this avenue that I now want to explore, because it seems to me 
to offer all sorts of possibilities in the developing field of process control. 

In Chapter 13 I dwelt at some length on the rather artificial distinction which 
has arisen between ‘Data Processing’ and ‘Office Automation’, and I suggested that 
APL is well suited to both fields. A similar distinction divides systems which basi- 
cally process information from systems which control and monitor machines: APL 
cannot yet bridge the gap but there are clear signs that it may. The essential prob- 
lem is that big mainframes are deaf, dumb, and blind to anything that doesn’t obey 
some precise and complex protocol. They also suffer from widely variable response 
times, and a 5 s delay in closing a valve could trigger a major disaster. 

This demand for instant, reliable response is met by the simple expedient of 
dedicating a mini-computer to control each cluster of machines; the IBM system/7 
is such a computer, and has been the subject of a very interesting implementation 
of APL (Alphonseca et al., 1977). Using shared variables, this APL can issue 
requests such as 


AI MOD 5,POINT 14,INTV 200, NVAL 10 


to read 10 consecutive values (at 200 ms intervals) from point 14/module 5. The 
result is an APL vector (length 10) of values in millivolts. Suppose an electric kettle 


172 


was plugged in to a microswitch (activated by 500 mV) at point 12; to make tea, 
we would place 


AO MOD 5,POINT 12 


into the control variable, and 500 into the data variable. This may seem an odd use 
of APL, but the fact is that many process control systems must handle matrices 
(e.g. 200 readings from 10 sensors), often of binary values. APL is clearly an excel- 
lent tool for this particular job, but more important is the possibility of unifying, 
say, a production planning system with the actual machines being planned. A 
possible configuration would be 
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workspace 


a 


00000 0 
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In this case, the traffic is one-way only: the sensors attached to the plant return 
information to an APL workspace, which aggregates it in some way, and logs it 
periodically into a database (probably another APL workspace in practice). This 
information can be accessed when needed by a production planner, who can use it 
to make up-to-the-minute judgments about possible changes of schedule. 

The next stage is obviously for him to feed such changes of plan back into the 
database, ready to be picked up by the control workspace, which will then take 
appropriate action. Clearly, further workspaces could take care of such tasks as 
ordering materials, working out the wages, analysing absentee statistics, ensuring a 
sensible maintenance schedule, and so on. The beauty of such a unified approach is 
that the possibilities are virtually endless, and with APL shared variables, and distri- 
buted decision making we can exploit them to the full. 

That is my view of one possible future; it is obviously conditioned by my 
personal experience, which has been of VS APL used ‘in the raw’ for a wide variety 
of decision-support systems in a large and complex manufacturing company. I have 
placed very little stress on the development of APL packages, because I have never 
yet come across an application which could not be more easily satisfied with a pur- 
pose-built system. Building-bricks and system utilities, of course; but somehow the 
next level up never quite seems to work as well. Perhaps it’s just that my company 
does things in strange and unusual ways (e.g. a 13 month year), or perhaps the 
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world is not as simple as the package-writers would have us believe? We shall soon 
see who is right! 

Finally, I would like to close this look ahead with another quotation from Pro- 
fessor Ackoff. In his view, the classical Operational Research paradigm ‘Predict 
and Prepare’ contains an inbuilt contradiction, since by preparing for the future we 
invalidate our own prediction! He suggests a new paradigm: 


"... design a desirable future, then invent ways of bringing it about’. 


APL is just a better way of inventing desirable futures. 


Epilogue 


My experience in computing has been of interactive BASIC (at university), several 
years of batch PL/1, a bit of FORTRAN, Z-80 assembler, and APL. I approached 
APL with a fair degree of suspicion - surely computing couldn’t be that easy? - but 
(always happy to try something new) I used it to have a crack at a production 
planning system which had become rather bogged down in PL/1. In about two 
months I had progressed from an unwieldy tray full of cards, an algorithm that 
didn’t work, and a reluctant user to an enthusiastically received system which pro- 
duced useful results at remarkably little cost. 

Since that time I have learned a lot about APL, but the basic conviction that it 
is simply a ‘better way’ remains as strong as ever. I know there are jobs it can’t 
tackle - payroll for 100 000 people, huge LP problems, making tea - but these are 
ruled out by limitations in the environment, not by any deficiency in the notation. 
APL is still years ahead of its time - one day it will do all these things, and with a 
clarity and simplicity that will astonish the computing world. 

The systems thinking of today has been brainwashed by the need to process 
data one element at a time; this has led to programming languages like BASIC and 
PL/1, and to an impressive range of techniques generally known as ‘structured 
design’. All these tools embody one (fatally flawed) assumption about the world 
- that it is hierarchical. They assume that data is held in files; files are composed of 
records; records are composed of fields. This is not true. Data is composed of 
patterns which may overlap, interleave, and interlock. It is only our limited view 
that has forced it into such an artificial and unrealistic structure - of course we can 
dream up a design method which will produce ‘perfect’ programs in such an over- 
simplified world! 

No such design method exists for APL, because in APL you can see all the data 
all the time - usually it’s quite obvious what you want to do to it, and usually 
your requirements can be expressed asa couple of APLsymbols! One final example: 
a company prints 9999 special-offer slips, and sends out all those which don’t get 
chewed by the addressing machine, pocketed by employees, etc. It records the 
numbers of those it actually sends, and logs the numbers of the replies received. 
The object is to send the manager a report 


Offer no. Result 


1 Never sent, no reply 
Sent, no reply 
etc. 


for the four possibilities. (If there are any replies to unsent offers, some luckless 
employee is doubtless due for the high jump!) For one solution see ‘Principles of 
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Program Design’ (Jackson, 1975); the point is that if you are forced into processing 
one item at a time from the two separate lists (SENT and RECEIVED) then this 
really becomes rather a difficult problem. You must correctly synchronize the way 
you read the files, and you must also cope sensibly with the possibility of running 
off the end of either, or both. Why do we insist on making life so difficult for 
ourselves? 

Traditional programming methods produce difficult solutions to trivial problems, 
and cannot hope to tackle anything subtle. APL treats trivial problems (like the one 
above) to trivial solutions, and gives us hope that it will not make the difficult 
ones impossible. In writing this book, my overwhelming feeling has been one of 
ignorance; of just how little we know about these new tools called computers. We 
are in much the same position as the engineers of the eighteenth century - building 
steam engines without any idea of the laws and science of thermodynamics. Their 
machines worked (after a fashion); occasionally they blew up and killed people; 
their development was painfully slow - but they worked, so people kept on building 
them. Eventually, one or two very clever people began to understand why they 
worked, and suddenly we had steam locomotives which could pull a train from 
London to Aberdeen in eight hours. 

The day is still a long way off when a computer will reliably deduce that ‘Time 
flies like an arrow’ is semantically rather different from ‘Fruit flies like a banana’, 
but that day will come, and the development and spread of APL has brought it 
significantly closer to hand. I hope this book may have made some small contrib- 
ution to the development and spread of APL. 


Appendix: Recommended reading 


This appendix is split into three sections: general background; books about APL; 
and references to the specialist literature. It largely reflects my own reading habits 
and preferences, and obviously is not totally representative. 


Background 


Under ‘background’ I would include most of the regular computing magazines, and 
two works of literature: The Machine Stops by E. M. Forster and Future Shock by 
Alvin Toffler. Another powerful contribution to the debate is The Mighty Micro by 
Dr Chris Evans. Finally, everyone who writes dialogues should hear Arthur Dent’s 
altercation with the Nutri-Matic Drinks Synthesizer from the BBC radio programme 
‘The Hitch Hiker’s Guide to the Galaxy’ (Series 2, Episode 2) (also published in 
book form as The Restaurant at the End of the Universe by Douglas Adams). It 
stands as an awful warning to us all! 


APL Books 


Next the APL books, and one stands head and shoulders above the rest. “APL - An 
Interactive Approach’ by Gilman and Rose gets better every time I read it. They 
have achieved the remarkable feat of producing a book which can be understood 
by the novice, yet read in bed by the expert with undiminished pleasure. I hope 
they never change it! Another old chestnut is Paul Berry’s APL\360 Primer - I 
have never seen a better introduction to what APL is and does. It reads so well, for 
one thing, and it’s a far pleasanter way of learning the language than ploughing 
through one of those dreadful PI texts. 

On the theme of learning APL, there is ‘APL: The Language and Its Usage’ by 
Polivka and Pakin, and Structured Programming in APL by Geller and Freedman. 
The latter is quite a good APL tutor, but only actually mentions structured pro- 
gramming twice - on the title page and in the epilogue! Both of these seem to me to 
be books to get from the library to read once; you want Gilman and Rose on your 
desk as a permanent fixture! 

At the next level up, most of the literature is of a rather mathematical/technical 
nature; however, I would recommend APL in Practice for general reading. As might 
be expected from the proceedings of an STSC conference it is somewhat bureau- 
oriented, which means that you have to wade through a host of ‘Isn’t our package 
wonderful - please buy it’ papers. Nevertheless, there is plenty of good stuff there, 
and you may want a ‘bureau’ perspective to balance my ‘in-house’ view! Of course 
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there is more to writing a good APL system than just knowing APL, and James 
Martin’s Design of Man-Computer Dialogues should be included in any APL train- 


ing program. 
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